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.