Re: gnustep-base code freeze

[Richard Frith-Macdonald]

On 25 Mar 2011, at 23:29, Stefan Bidi wrote:

> I absolutely agree we need a good project wide release policy.  I really like 
> what you outlined below, but does it fit with the way GNUstep does things?
> 
> On Thu, Mar 24, 2011 at 7:21 AM, Nicola Pero <address@hidden> wrote:
> I'm not sure what the current release policy is (well, I know for 
> gnustep-make);
> I think it changed a few times.  If we're discussing it, I have a bit of time
> today and will suggest what I think would be good.  (feel free to disagree; 
> and
> I may not have time to follow up on the discussion).
> 
> If I can suggest an example of a good release policy, I'd suggest the 
> postgresql
> one.  They seem to follow the following policy:
> 
>  * all releases are "stable"
> 
>  * a new "important" release (binary-incompatible with the previous one) every
>   18 months or so (eg, 8.4.0, 9.0.0, etc).
> 
> So major and minor releases are abi-incompatible... I'm all for that, but 
> then what's the point of that void * at the end of every class?  Personally, 
> I don't like it after working on the 2 formatter classes.

The pointer to internal data lets us hide the class implementation details, and 
means we can make changes/bugfixes without breaking binary compatibility.  
Nicola is proposing maintaining binary compatibility in each major release for 
many years.

> When would GNUstep every have a major number bump?  The way I understand it 
> now, never.  It than begs the question, but does the major number mean to 
> GNUstep?  Obviously GUI and Back have no yet reached 1.0 status, so I can see 
> that, but after it does reach 1.0 status, when will base and gui be bumped to 
> 2.0, 3.0, etc?

The major release number is for pubic relations ... when a big publicity 
milestone is reached.  I think that's something primarily for Greg to decide on.

>  * each "important" release gets small, bugfix-only, binary-compatible 
> releases
>   for many years (eg, 8.4.1, 8.4.2, 8.4.3, etc)
> 
> I really like this idea (very, very much actually), but does GNUstep plan on 
> concurrently supporting multiple version?  I assume postgresql, like FreeBSD, 
> has at least 2 different "stable" branches (in the fbsd's case you have the 
> 8.2-release and 7.4-release) at any given time.  I really like the idea, but 
> is it feasible with the amount of work something like this would create?

At present the policy is to have two releases at any one time ... we've been 
calling them 'stable' and 'development', but I think we are all agreed that's a 
bad idea because distributions will only look at the 'stable' version, and in 
fact, for gnustep-base there's no real stability difference between the two.
I don't think it would make much difference to have multiple releases/branches 
... we don't actually need to spend significant extra time maintaining the 
older branches if we just say that people who want bugfixes backported to older 
branches should supply the patches to do that.

> Like I said, I really like what you outlined here, just wondering if it'll 
> actually work and GNUstep will stick to it--the release policy has changed at 
> least twice since I've been following the project.

I'm not sure what you consider a change.  My recollection is that we went from 
having no formal policy to having one, and now we are considering changing it,  
essentially by changing the naming and by providing bugfix releases for older 
versions.

Here's how the change would work:

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.