Re: gnustep-base code freeze

[Richard Frith-Macdonald]

On 1 Apr 2011, at 22:08, Fred Kiefer wrote:

> On 01.04.2011 11:09, Nicola Pero wrote:
>> 
>>>> In this model, instead of a single branch in the svn repository for
>>>> the current stable release, we would have a branch for each important
>>>> release, allowing us to make bugfix releases in each branch if we
>>>> want.
>>> 
>>> I am not sure I understand how this is supposed to work. One thing that we 
>>> need to guarantee is that we always know what is included in a specific 
>>> release, given the release number. This condition seems to be broken in 
>>> your proposal. It looks like the same release number could be subsequently 
>>> used for a "stable" and a "development" release.
>> 
>> You could do as follows:
>> 
>>  * every now and then (say, every 12 or 18 months) make a new "important" 
>> release.  So, you take trunk, make a release and a branch, and call it (say) 
>> 1.20.0.
>> 
>>  * then, you increase the version number in trunk to 1.21.0.
>> 
>>  * after 12 or 18 months, when you want to make a new "important" release, 
>> you take trunk, increase the version number to 1.22.0, make a release and a 
>> branch.
>> 
>>  * you increase the version number in trunk to 1.23.0.
>> 
>> So, you'd use the even numbers for actual releases, and odd numbers for 
>> development snapshots.  Then, you always know what is included
>> in a release.
>> 
>> Alternatively, we can append "alpha" to the release number (like most other 
>> projects do), ie when we release 1.20.0, we change
>> the version number in trunk to be 1.21.0alpha, which will become 1.21.0 upon 
>> release.  That may be the simplest and easiest
>> to understand ?
>> 
>> So, if trunk is in development for what will be gnustep-base-1.21.0, then 
>> the release in trunk would be 1.21.0alpha.  Of course the 'alpha'
>> would mostly appear in user-readable strings; macros/version numbers would 
>> still report 1.21.0 if you query via an API.
> 
> This proposal actually sounds rather nice to me. Maybe this was what Richard 
> did propose all the way. I just didn't understand it. Even though we will 
> waste all the odd numbers, the version with actual numbers for trunk suits me 
> better. But this isn't a big deal.  The important thing is that we no longer 
> will have two releases at once, which confused people and packagers.

Almost identical (I didn't have the idea of adding 'alpha').

Concrete example ... about a year ago we released base as stable 1.20.0 branch 
and development 1.21.0
So, our next release would be base-1.22.0
trunk would become 1.23.0
we do development work and fix bugs in trunk, maybe in the summer we fix an 
important bug and decide make a release with it
so we backport the fix to the 1.22 branch and make a 1.22.1 bugfix release
later in the year we find another bug worth backporting to the 1.22 branch, and 
we make a 1.22.2 bugfix release
after a year or more we decide to to a new release with all the new development 
work, so we copy trunk to a 1.23 branch and make the base-1.23.0 release, 
incrementing the version number in trunk to 1.24.0

All releases are 'stable' ... we don't do development releases.

We *might* (but won't necessarily) want to make development snapshots available 
during the year,  but these are not 'releases' and don't get separate version 
numbers.
We also might (but won't necessarily) want to backport bugfixes to earlier 
releases, providing support for older releases ... in which case we could 
release 1.20.2 (the 1.20 branch is currently at 1.20.1) or 1.21.2 etc

I like the idea of trunk being classified as 'alpha'.

We could tag any snapshots we make as 'alpha' , but I'd also like to tag them 
with the date they were created.
Automating that could be a good option.  Changing tagging of snapshots from 
'alpha' to 'prerelease' shortly before we are planning to make a new release 
might also be nice.