Backport fix for BZ #18928?
Carlos O'Donell
carlos@redhat.com
Thu Jan 1 00:00:00 GMT 2015
On 12/17/2015 12:36 PM, Joseph Myers wrote:
> On Thu, 17 Dec 2015, Carlos O'Donell wrote:
>
>> On 12/17/2015 12:02 PM, Joseph Myers wrote:
>>> I think bumping the version number to 2.22.2 should imply making a 2.22.1
>>> release (which means updating the release checklist to make clear which
>>> bits apply to point releases, e.g. tagging and release tarballs and
>>> announcements, and which don't, e.g. branching - and probably also a
>>> variant of the release announcement that makes clear this is a point
>>> release with just a few bug fixes, not a major new release).
>>
>> Would you be opposed to having the VERSION bump on a released branch
>> contain no work required by the committer?
>
> Yes. I don't think the number should be bumped past 2.22.1 without a
> defined set of sources for 2.22.1, and as per the announcement to gnu-prog
> on 7 May, GNU package releases should include tarballs, not be tag-only.
The consequence of this is that we will likely have no official point
releases from stable branches because the cost is simply too high until
someone provides enough automation to make it easy to turn out a new release
for those with upload authority.
Therefore I withdraw my suggestions and leave the stable branches to accrue
patches and to be used as the downstream developers see fit.
In the case of Fedora we may simply continue to rebase against the stable
branch without a release. Which is fine for us.
I understand the desire for a "release" to mean something particular for
GNU projects and include tarballs, not tag-only, but that's simply too high
an amount of work right now for the people we have working on this.
And while GNU won't have official glibc 2.22.2 release, downstream probably
will e.g. 2.22-2 etc., but that will follow downstream rules.
Cheers,
Carlos.
More information about the Libc-stable
mailing list