On Wednesday, 12 December 2012 at 19:28:54 UTC, Rob T wrote:
2.61.0 => bugfixes => 2.61.1
2.61.0 => newfeatures => 2.62.0 beta 1
2.62 => preparing for stabilizing => 2.62 rc1
just some thoughts.
A 3 point numbering system used to differentiate between the
stable bug fix releases and the beta version works just fine,
and there's no need to introduce descriptive symbols, although
that can be useful to indicate what is stable, beta or alpha.
So I say let us stay away from beta/alpha because those mean
something different for different people and we need to define
what they mean in D.
1. Bug fix only (how important is backwards compatibility here
[when derived from a bug])
2. Backward compatible additions
3. Vetting
This seems to be the main releases that are being talk about. For
which you are probably talking about the ability to use a 3 point
system.
The mapping I think people envision from this
1 & 2 => stable release
3 => dev release
[side rant]
When doing version numbering there are two main approaches I've
seen used, maybe this has a formal name, but I'll call them front
loaded and back loaded.
Front loaded version generally comes from having goals/milestones
for a version. In this case all the work for that version comes
before the release. This is generally seen pre-1.0 as that will
be the stable release.
Back loaded is what generally comes from deciding on a new
direction and where D currently is. In this case all the work is
done within the version. This is generally seen in 2.0, software
is released with the 2.xx stamp but is not fulfilling all the
requirements needed to meet being the second version.
[/side rant]
I'd like to see what you envision for mapping these versions.
vetting.additions.bug?
Do we release a stable then increment vetting and develop under
that (back loaded)? Or
stable.vetting.additions/bug
Do we increment stable upon release and continue increasing
vetting as we release those for the volatile changes. (front
loaded)
