On Mon, 16 May 2005 08:28:05 -0500, Tom 'spot' Callaway wrote:
On Mon, 2005-05-16 at 12:03 +0200, Michael Schwendt wrote:
No, it isn't. Surely you can avoid the necessity to bump release for all branches.
Upon rereading your original mail, I still don't see how this is avoided. Can you help me understand how the following test cases would work:
(Assume that FC-3 and FC-4 are current, FC-5 in devel. Also keep in mind the aforementioned Golden Rule, that packages in FC-3 < FC-4)
- The Normal Case
In the FC-3 repo, you have:
foo-1.0-1.noarch.rpm
In the FC-4 repo, you have:
foo-1.0-2.noarch.rpm
You need to errata the FC-3 repo.
First of all, more normal would be that the FC-4 package suffers from the same defects than the FC-3 package, so both branches need an update. In that case it's a scenario where dist tags make sense.
If however you really mean that no erratum for FC-4 is needed, you would not bump its release just make your "golden rule" happy, but instead keep the FC-3 erratum "older than" the latest FC-4 package:
foo-1.0-1.noarch.rpm (FC-3) => foo-1.0-1.2.noarch.rpm (erratum for FC-3)
- The CVS Case (disconnected)
In the FC-3 repo, you start with:
foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
In FC-4, you need a later checkout:
foo-0.0-1.20050515.noarch.com
The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4 does not.
This is my earlier example. Solution as above:
foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
- The CVS Case (same source)
In the FC-3 repo, you start with:
foo-0.0-1.20050515.noarch.com
You use the same cvs co for the FC-4 repo:
foo-0.0-1.20050515.noarch.com
Resolve the conflict in naming between branches, and perform an FC-3 only package errata.
Same as 1.
The example is flawed, because it violates your golden rule already prior to the needed erratum.
(Note that I have avoided dist tag usage on purpose to avoid "complicating" the issue, but if they're useful in your solutions, feel free to reintroduce them here)
Thanks in advance,
Dist tags don't help in these cases, since they are the least significant portion of EVR and don't add any value if you bump the most significant portion of Release only on an older branch.
[...]
We can continue to collect and examine problematic cases and possible solutions for them. E.g. ways to avoid Epoch inflation. But I'm inclined to say that the search for an ultimate versioning scheme would only result in a document much more complex than fedora.us' old versioning scheme.