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)
1. 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)
2. 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)
3. 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.