On Wednesday, 12 December 2012 at 18:33:17 UTC, Jesse Phillips
wrote:
If we release 2.61 as a stable, we would then develop new
features in which version? 2.62 beta 1? If so, when we release
2.61 with a bug fix which version do we release? 2.62? 2.61
stable 2?
You are right that version numbers have absolutely no meaning,
I don't remember if it was you, but they are also not as
important as the process improvements. However if we assign
meaning to numbers there can be benefit. Mozilla basically just
did away with the Major version. (I say we do a Linux and leave
the 2 then realize it has no meaning and up it to 3 when we
reach the age of the 2.0 kernel)
We should combine your beta with an added version number.
The beta foobar speaks of is actually a combined alpha+beta, and
that'll cause lots of problems and also delay releases because
the combined alpha+beta will have to be frozen at some point
prior to release as the next stable (i.e., frozen from
enhancements that are not bug fixes only). Freezing the
alpha+beta combo is not a problem for the beta portion, but it is
a problem for the alpha portion that has no requirement to be
frozen. You could just branch off the beta from the alpha into a
special frozen branch, but then what are you doing? It makes no
sense. Also important is that fact that there will be many
programmers who could not wait for the next stable release and
want to use the latest beta, but there is none, there's only and
alpha+beta combo, and that'll mean the current problem we have
right now will not be resolved where newly introduced features
mess up the beta portion that people want to be able to rely on
for real-world programming. The separation of alpha and beta
allows for a beta that is at least far more stable than an
alpha-beta combo, and that will satisfy the people who wish to
move past the stable release into a beta, but wish to avoid the
alpha entirely.
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.
In any event, I fully agree that the process is the most
important item to work out first and foremost. When I mentioned
version numbers, I simply wanted to remind people that it should
also be on the table for change AND should be included into the
process at some point to make it a well understood concept as
opposed to what we have now. The response I got from Foobar was
very surprising to me which is why I explored it further.
As was suggested in another post, I'll do a little digging to see
what is going on with the development cycle of other programming
languages. Best not to try and reinvent the wheel if we can. One
thing about D is that I suspect there's a sizable faction that
does not wish to do what other programming languages are doing,
and that's to avoid introducing breaking changes completely.
Personally I'd rather see flawed concepts get fixed at some point
rather than have to live with them forever, the point being that
we may be somewhat unique with our development process
requirements.
--rt
