On Tue, 2009-04-21 at 21:53 +0300, Axel Thimm wrote: > On Tue, Apr 21, 2009 at 01:02:50PM -0500, Callum Lerwick wrote: > > But putting the patchlevel in somewhere isn't a bad idea. I'd go with > > something like this: > > > > bash-4.0-1.pl16 > > bash-4.0-2.pl17 > > bash-4.0-3.pl18 > > So what would you do when upstream does consider releasing > bash-4.0.25.tar.gz, then again just uses patchlevels for say up to > bash-4.0.33.tar.gz, then goes bash-4.2.tar.gz and the story begins > anew? Your description sounds like this to me: bash-4.0.25-1 bash-4.0.25-2.pl1 bash-4.0.25-3.pl2 bash-4.0.33-1 bash-4.2-1 bash-4.2-2.pl1 etc. > Technically following the guidelines to the letter we would get > > bash-4.0-3.pl18 > ... > bash-4.0-4.pl24 > bash-4.0.25-1 > bash-4.0-1.pl26 (epoch bump!) > ... > bash-4.0-6.pl32 > bash-4.0.33-1 > bash-4.0-1.pl34 (again epoch bump!) Is that what you were trying to describe? If they do this, upstream should be slapped with a herring for using completely senseless release versioning. How is a *human* even supposed to know that 4.0 patchlevel 26 is newer than 4.0.25? In this hypothetical insanity, it would be *upstreams* fault for us having to use epochs, not our fault and not a fault in our guidelines. > The official patches by upstream do intenionally increase the version > of the source and bash --version reflects that. So upstream's > intention is that this source conglomeration is bash-4.0.17, not > bash-4.0 with some patches. Interesting. No, upstream's intention is not clear. The tarball versioning and internal versioning conflict This is a case where upstream is being unclear and we simply need to communicate with them to sort things out.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
