Re: gnustep-base code freeze

[Fred Kiefer]

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.

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.