At present we have continuous builds of ren-c as commits made which makes choosing a stable release difficult.
I'm suggesting we choose a core set of commonly used programs/utilities and test them against the new builds. If they all pass, then the new build becomes the candidate for the new stable release. If the tools fail, then they need to be amended until they work again before we decide on the new stable release. If they can't be fixed, then we decide whether we can still use that tool.
For the first suggestion, I am suggesting that we chose existing module code as the corpus of code that we test against.
@rgchris Does that suit you since you're the author of the most used modules!
The main criteria for me would be a feature freeze.
This is what happened to Perl6 and part of the reason it dragged on so long Eventually they agreed on a drawing a line in the spec and called it v6.c (an interim version) and then released this as beta Perl6 (Rakudo Star on Xmas day 2015).
So it's pretty much just bug-fixes only to v6.c (Rakudo Star). So module writers expect no or very little changes - https://modules.perl6.org/
There will be a separate branch implementing feature changes/additions which will eventually become v6.d or v6.0. At some point in future there will be the new "stable" version released using this and modules may need updating!
At this moment I have mixture of scripts written in R3-Alpha and a Ren/C (compiled from July 2015). I definitely want to migrate all these to a brand spanking new Ren/C and will definitely do this when we have a "stable" release.
So boils down to whether there's any features @hostilefork wants to squeeze in or change before a freeze? Once ready we make a "stable" release and then it's then over to all module writers to test
A good starting point for testing could be modules in renclib. We'll need to create some tests for these.
That's why I quoted it each time. But I believe what we're both after is on the same hymn sheet
There's nothing stopping Ren/C from moving forward here. This would happen on separate "development" track (probably the master branch). While a "stable" branch would have bug-fixes only.
So to clarify here's an example of what I'm suggesting...
Stable version release agreed
Create "stable" branch
Version number applied to stable branch (perhaps 2.103.0) & commit
Next version (2.104.0) applied to master branch & commit
Travis build binaries from master & stable
Then at some point in future we agree new "stable" release and repeat the process (upping the version numbers).
NB. Above is a simple example so exact branching strategy, release cycle & nomenclature to be agreed.
It's good to be working on stability, and that is what I am trying to do... pinning down open questions and getting some final say on it. Whether that's how many underscores are in a blank, or what refinements to SET and GET are called, I would rather we have at least these basics ready.
It was only a week ago that ELSE and THEN really got "solved", and that's the kind of thing I want in a stable build.
So rather than declaring stable builds just yet, I'd prefer it if everyone got on board with helping hammer down things that are known-unknowns. We've got many more to go. And to get READMEs and the build process as streamlined as it can be.
The faster people work on pinning down the issues, the faster we can get to low rates of evolution.
But I've mentioned before it is not fair for me to work for a couple years, keep throwing things out there and trying them, refine it to my best understanding...get low amounts of feedback...and suddenly people go "okay, NOW, stop changing it".
Right now is great because of the increased feedback and participation. But we need to use this energy to get the resolutions you are seeking...not ask them to be finalized before the participation. I think it's starting to go at a faster clip, and so, let's keep up that clip and you'll have what you ask for.
But if we are to release scripts into the wild for public use, we need to specify a build that they can use instead of getting instantly frustrated. So, this is the reason we need to settle on something for public use.
Try not to recruit that kind of user quite yet. I like the idea of working with people who understand the system is evolving.
If it's any comfort to them, there will be a master/develop branch split. We will then patch any high priority bugs on both branches, without changing master's API. Atronix needs this, so it is a guaranteed thing in the future. I just don't want us to be impulsive about this choice without going through a checklist of issues I am concerned about.
We might have to make a Google Hangout some weekend, get all the stakeholders together, and just agree that we're not going to quit without having an answer to every line item I give that satisfies everyone in a futureproof-enough way.
I think we are going to bite the bullet and declare a stable version soon. Any versions after that that create user space incompatibilities will need a version bump.
Eventually they agreed on a drawing a line in the spec and called it v6.c (an interim version) and then released this as beta Perl6 (Rakudo Star on Xmas day 2015).