[GRASS-dev] GRASS 6.3.0 release preparation

[Paul Kelly]

On Sat, 11 Aug 2007, Glynn Clements wrote:

> Paul Kelly wrote:
>
>> I was just thinking, the Python GUI can probably be merged into the CVS
>> HEAD after a release branch has been created for 6.4.x (probably won't be
>> ready for that for at least a couple of months). Then there will be 6.5.x
>> - we can probably start making other major changes there and release it
>> eventually as 7.0? How does that sound?
>
> I'm disinclined towards the creation of 6.4/6.5 versions. I would
> prefer to see stable = 6.3.x, dev = 7.0-cvs.

But that breaks with our convention of having odd sub-versions (5.3, 6.1 
etc.) for incremental releases of "under-development" versions and even 
sub-versions (5.0, 5.4, 6.2 etc.) for releases of stable versions with 
incremental bugfixes.

The way I see it, we should be making reasonably regular 6.3.x releases 
right now from the CVS HEAD. These are just development releases, to 
encourage people to test the latest developments, without having to get a 
CVS version. I actually think there's a good argument for releasing 
development versions at fixed intervals (e.g. every 2 months) - keeps 
everything well tested, adds a bit of motivation for developers to finish 
up new features shortly before a release is due and that kind of thing.

With that logic in mind I really think we should release 6.3.0 straight 
away, right now - it isn't necessarily supposed to be totally stable - and 
then release successive 6.3.x releases, if necessary, in the next couple 
of months until we feel we're ready for a stable release - then we create 
a branch in CVS and release 6.4.0 from that.

And after that the CVS HEAD is freed up to start putting major changes in. 
What the next version is called is a different issue though, but I think 
the move to SVN should be transparent and we don't need to use the actual 
move as a tool to help out version control - the situation with the two 
repositories for 5.0 and 6.0 resulted, as I understand it, because 
development on 6.x (then called 5.1.x) started way before 5.0.x had had 
its first stable release, and it was impractical to develop them both from 
the same repository. I think we're better organised enough now not to have 
to do that.

Anyway version numbering - I don't see how we can ever call the CVS HEAD 
7.0-CVS - because 0 is an even number - 7.0-CVS implies incremental 
bugfixes to an already-stable 7.0 version??? That's what it seems to me. 
How would incremental development versions be numbered then? Considering 
6.2-CVS and 5.4-CVS - those both correspond to ultra-stable CVS 
branches that only have occasional bugfixes added to them. Much as in 
5.7-CVS became the 6.0.0 stable release, it seems to me (or it *did* seem 
like that ;) that after the 6.4 branch is created, the CVS becomes 
6.5-CVS, and this eventually becomes 7.0.0. BUT that breaks with the logic 
than changes in sub-version number should not result in major incompatible 
changes. This seems to be a flaw in our version-numbering system that I 
never noticed before, and I'm a bit stumped by it. Perhaps everyone else 
realises it already and that's why no one else is as pedantic about the 
version numbering as me.

I suppose the question really boils down to are we going to abandon the 
sub-version numbering (odd development, even stable) system, or not? I feel 
it hasn't been totally unsucessful, but we really should have made more 
out of it by releasing more development versions. As far as I remember it 
was supposed to be similar to the Linux kernel system, and wonder how they 
handled the numbering of development releases before a major version 
number change - but (a) I don't think there's been one in the last 9 
years, the time I've been using Linux anyway and (b) I suspect their 
system is also changing too as they find different ways of working. 
Bernhard used to have some interesting thoughts about this sort of thing; 
I wonder if he is still listening.

Anyway, I just wanted to make clear why I suggested a 6.4 release branch 
followed by 6.5 CVS leading to 7.0.0. Although now I'm not quite as sure 
what's the most logical way forward...

Paul