Re: gnustep-base code freeze

[Richard Frith-Macdonald]

On 1 Apr 2011, at 09:44, Fred Kiefer wrote:

> On 01.04.2011 07:45, Richard Frith-Macdonald wrote:
>> When making an important release, current policy is to actually make
>> two versions (eg if trunk is on 1.19.x we would make 1.20.0 and
>> 1.21.0) ... one for the 'stable' branch and one for the 'development'
>> branch (trunk) going forward.  Then bugfixes would be backported to
>> the stable branch (bugfix releases 1.20.1, 1.20.2 ...) and new work
>> would be done in the development branch with minor releases from that
>> (1.21.1, 1.21.2 ...). We have a branch in the subversion repository
>> for the stable (1.20.0) release and for all the bugfix releases
>> (1.20.1, 1.20.2 ....) made to that.
>> 
>> The policy change would mean we drop the stable/development
>> distinction so that a new release consists of one new version being
>> branched, and subsequent bugfixes being backported to that branch
>> (and possibly to branches for earlier versions).  I guess as far as
>> version numbering goes, the development branch (svn trunk) would
>> always use the version number expected for the next release, so when
>> we make a release the release gets the version number from trunk, and
>> in trunk we increase the version number to be that of the next
>> release (we could alternatively say that trunk always has the same
>> version number as the most recent release ... I'm not sure if that
>> makes more sense). eg. if trunk is at 1.20.1 then we do a 1.20.1
>> release and change trunk to be 1.20.2 for the next minor release the
>> version would be 1.20.2 and trunk would be incremented to 1.20.3
>> then, if we want to make an important release, we do a 1.21.0 release
>> and set trunk to be at 1.21.1 and if we want to backport a bugfix to
>> the 1.20 branch we would release that as 1.20.3 (ie increment the
>> subminor version number)
>> 
>> 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.

That's impossible because the whole point of the change is that we no longer 
have stable and development releases, only stable ones.  I suppose in theory 
you could run out of version numbers for an old release, but in practice that's 
almost impossible (I guess if it ever happened we'd just stop backporting 
bugfixes to the old release eg. if you get to 1.20.99 then you stop supporting 
the 1.20 release) since even if we made a bugfix release each month it would 
take several years to count up from 0 to 99

> I would prefer to stick with an interpretation of our current release schema 
> that means we release two identical snapshots of our code when ever we do a 
> release. We call one stable and the other development and they are one minor 
> number apart. Then we do compatibility breaking changes on the development 
> branch (being trunk) and sometimes backport non-breaking changes to the 
> stable branch and increase the subminor number of that from time to time when 
> we release that code. The development branch wont get any intermediate 
> releases. Everybody who is following that will be on his own and needs to 
> update from SVN.

Well, if you aren't  doing any releases from the development branch, I can't 
see how that differs from what I described apart from:
1. you retain the stable/development terminology rather than referring to 
release by version
2. you create an extra snapshort and an extra minor version number at each 
release which you never use for anything
3. you presumably never backport bugfixes to earlier releases, only to the most 
recent 'stable' release 

I don't really see any of those things as advantages (and point 2 seems 
something of a disadvantage).