[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep-base code freeze

From: Fred Kiefer
Subject: Re: gnustep-base code freeze
Date: Fri, 01 Apr 2011 23:08:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]