gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Versioning/release policy proposal


From: Fred Kiefer
Subject: Re: Fwd: Versioning/release policy proposal
Date: Fri, 06 Oct 2006 20:16:12 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060911)

I like this proposal very much, there is one area, where I see problems,
but we could wait until we actually face them. This is the question, who
will be willing to work on the bugfix releases?
Most developers will spend their time and efforts on the new unstable
release, then somebody needs to decide that some change to the unstable
release is worthwhile to be ported back to the last stable release,
integrate it there and make a release. The procedure itself sounds fine,
but as long as nobody volunteers to actually follow it, it wont help.
Any volunteers?

Fred

Richard Frith-Macdonald schrieb:
>> 4. Release stability policy
>> We advertise a 'stable' release *every* time we break backward
>> compatibility.  Doing this requires making two releases pretty much at
>> the same time and bumping the minor version number for each.  Eg. if
>> the last release was 1.3.24 then we release 1.4.0 as 'stable' and
>> 1.5.0 as 'unstable', each with the appropriate change in the SONAME. 
>> All releases (if any) in the 1.4 family would be bugfix releases.
>> I suspect the vast majority of people would just use the 'unstable'
>> releases (largely defeating the point of having 'stable' ones), but
>> the overhead of doing a 'stable' release is very low, so I don't see
>> why we shouldn't do it.
>> We can make 'stable' releases be those with even subminor version
>> numbers.
>>
>> 5. Standard release procedure (backward compatible with previous version)
>> a. tag the version for release using the name_major_minor_subminor
>> convention.
>> b. make tarballs and installation packages
>> c. bump the subminor version number in trunk
>> d. put release on ftp site and publicise
>>
>> 5. Standard release procedure (NOT backward compatible with previous
>> version)
>> a. bump the minor version number and SONAME and reset the subminor
>> number to zero
>> b. tag the version for release as 'stable' using the
>> name_major_minor_subminor convention.
>> c. make tarballs and installation packages
>> d. bump the minor version number and SONAME and reset the subminor
>> number to zero
>> e. tag the version for release as 'unstable' using the
>> name_major_minor_subminor convention.
>> f. put releases on ftp site and publicise
>>
>> 6. Bugfix release procedure
>> a. if this is the first bugfix release of a package version, make a
>> branch from the tagged release using the tag name as the branch name
>> eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the
>> branch is foo/branches/foo_1_2_0
>> b. apply bugfixes to the branch
>> c. tag the branch as foo_1_2_0-1
>> d. make tarballs and installation packages
>> e. put on ftp site and publicise
>> NB.  we only ever make 'bugfix' releases in 'stable' release families,
>> and these are the only sort of releases we make in those families.
>>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]