Next focus: PROCESS

[Rob T]

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