Re: gnustep release numbers

[Gregory John Casamento]

I agree with this...  we should bump the library version immediately after, to 
eliminate confusion.
 
--
Gregory Casamento

----- Original Message ----
From: Richard Frith-Macdonald <address@hidden>
To: Helge Hess <address@hidden>
Cc: Developer GNUstep <address@hidden>
Sent: Wednesday, October 4, 2006 7:30:08 AM
Subject: Re: gnustep release numbers


On 4 Oct 2006, at 11:51, Helge Hess wrote:

> Hi,
>
> could we please change the numbering scheme for GNUstep releases?
>
> In my understanding:
> Currently when Adam does a release he bumps the soname version (eg  
> from 1.12.0 to 1.13.0) in trunk and then tags the release. That  
> means after the release, trunk will continue carrying that tag.
>
> I propose a simple modification: Also bump the version after a  
> release so that trunk libs can be identified properly.

I proposed somethog similar back in August ...

> On Aug 9, 2006, at 7:10 AM, Richard Frith-Macdonald wrote:
>
>>
>> I understand the problem, but I don't think the best solution is  
>> to add new macros and scripting.  Rather, I think it's to adopt a  
>> slightly more rigorous approach to making releases.  What I  
>> propose is this ...
>> When we make a release, we make a branch in svn into which any  
>> bugfixes will be applied.
>> Immediately after making the release, we increase the minor  
>> version number in trunk.
>>
>> After a release, if we need to make a bugfix release, we do it by  
>> incrementing the subminor version number in the branch and  
>> releasing a snapshot of the branch at that point.  We don't add  
>> new features in bugfixes, so there is no issue with version macros.
>>
>>
> I think that's a great idea, if we can get all the developers to be  
> rigorous about making changes to the correct branch - only bugfixes  
> (and ALL bugfixes) to the branch, etc.  It also helps with  
> releases, as I don't have to wade through ChangeLogs and source to  
> see if a new release deserves to be a major or minor release.

In fact, this is already done for the base library, but not the other  
packages yet ... we need to remember to do it promptly after a release.

> I would also suggest to use even numbers for releases and odd  
> numbers for trunk.

> That is:
> Lets bump the trunk version to 1.15.0 _now_. Next release will be  
> 1.16.0 and right after its tagged, we bump trunk to 1.17.0. And so on.

I'm not really happy with this idea ... I know the Linux kernel used  
to have that convention ... but most projects don't and Linux has  
dropped the convention since the 2.6 kernels started coming out.  It  
doesn't seem particularly helpful.

Where someone wants to take a snapshot and distribute it to customers  
etc, I think they really should implement their own separate version  
control for this.  Just saying that snapshots of trunk after version  
2.10 (for instance) have version 2.11 will not help them, since they  
might distribute different releases of their product with different  
snapshots from the same version of GNUstep ... all of which would be  
version 2.11 but all different, possibly with vendor specific  
modifications which haven;t made it back into trunk yet!

> Still less than ideal because we have no stable version but an  
> improvement over the current situation which makes it hard to  
> distinguish dev snapshots from final releases.

I don't think we have a policy of making unstable releases ... so all  
releases are stable.
Snaphots and access via SVN are obviously unstable.




_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev