[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep release numbers
From: |
Gregory John Casamento |
Subject: |
Re: gnustep release numbers |
Date: |
Wed, 4 Oct 2006 06:51:22 -0700 (PDT) |
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
- Re: gnustep release numbers, (continued)
RE: gnustep release numbers, Nicola Pero, 2006/10/04
Re: gnustep release numbers, Gürkan Sengün, 2006/10/05
Re: gnustep release numbers, David Wetzel, 2006/10/04
Re: gnustep release numbers,
Gregory John Casamento <=
Re: gnustep release numbers, Gregory John Casamento, 2006/10/04