Actually, the release candidate is the ‘b’ release in Greg’s parlance, which usually exists for a very brief time. If you look at the GitHub releases, we did make a 4.2.b.0, followed a week later by the official 4.2 release. It’s my understanding the HEAD is considered alpha code until right before an official release. Radiance major versions are released when they are released, generally following a brief period where it’s considered ‘beta’, and then the version goes back to ‘a’ in the HEAD and stays there until shortly before the next major release, again to ‘b’, and then, new version number. Twas ever thus.
At NREL we hang an additional identifier after the ‘a’ on each of our “releases” (which are really just snapshots, or tags), just to keep them in order. It’s not true semantic versioning, but it’s a way for us to keep track of which tag we’re using with which OpenStudio releases and whatnot. It can be confusing because our v5.0.a.5 predates the official release v5.0, which itself predates the latest set of packages we made: v5.0.a.8. > On Mar 12, 2016, at 7:24 PM, Randolph M. Fritz <[email protected]> wrote: > > It occurs to me that what we are calling a "release," the rest of the world > has taken to calling a "release candidate" -- the version that is almost > complete, but still has a couple of annoying bugs hiding that users identify > as soon as they put it into service. Perhaps this would be a convention we > could adopt. > -- > Randolph > _______________________________________________ > Radiance-dev mailing list > [email protected] > http://www.radiance-online.org/mailman/listinfo/radiance-dev _______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
