Criteria for stable r3/ren-c releases

Development Testing
#1

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!

2 Likes
#2

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 :frowning: 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 :slight_smile:

A good starting point for testing could be modules in renclib. We'll need to create some tests for these.

1 Like
The Path to Beta/One
#3

Yes.

Extraneous

Nothing to see here.

#4

@draegtun Perhaps I'm using the term stable release different from you :slight_smile:

ren-c is a constantly moving target and there's no feature set defined that would make a stable release as previously defined in rebol2.

I'm looking to define a stable build that we can rely upon.

And I agree we need a suite of tests for the modules we chose to define this.

1 Like
#5

That's why I quoted it each time. But I believe what we're both after is on the same hymn sheet :slight_smile:

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.

#6

I've just uploaded the latest builds to see if we can agree to a stable download

https://s3.amazonaws.com/metaeducation/stable/0.4.40/r3

So, it's

rejoin [https://s3.amazonaws.com/metaeducation/stable/ os_id "/" %r3]

or

rejoin [https://s3.amazonaws.com/metaeducation/stable/ os_id "/" %r3.exe]

Apart from the fact that the win32 build doesn't run, any objections to this type of scheme?

So, your linux user just has to

wget https://s3.amazonaws.com/metaeducation/stable/0.4.40/r3

for the latest stable build against which the major tools have been tested.

#7

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 Path to Beta/One
#8

But we have to decide on what we are going to test scripts against, and we can't cope with evolving syntax.

#9

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.

#10

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.

#11

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 should make this list.

#12

I don't think we really can decide who will use our scripts.
That's why I wanted something in the header to indicate a particular range of builds.

#13

For an interim solution until we get the master/develop branch split how about we just bump the version number on a regular basis?

This gives us a fixed community release cycle (every N months) so that we can...

  • See whats changed/fixed (between releases) in the CHANGES file

  • Test renclib (and other modules) against last version release & also latest dev build

I think this will provide benefits to all.

Obtaining a static url for the latest builds?
#14

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.