| 1 |
On Sat, 17 Mar 2007 10:46:22 +0100 |
| 2 |
"Marijn Schouten (hkBst)" <hkBst@g.o> wrote: |
| 3 |
|
| 4 |
> One thing we could do would be to separate hierarchy from version |
| 5 |
> naming. |
| 6 |
|
| 7 |
This is where upstream version numbers fail to have a decent order |
| 8 |
(like your example where later versions have lower version numbers). |
| 9 |
It could be done for example by extending metadata to include |
| 10 |
definitions of unnatural ordering, but I don't think it's worth the |
| 11 |
effort. So far we deal with that on a case-by-case basis, and live |
| 12 |
with the pain when it occurs. |
| 13 |
|
| 14 |
> This would prevent cases like currently with rosegarden (~)1.2.4 |
| 15 |
> (~)1.4.0 4.1.0-r1 4.1.0-r2, where it really should be 4.1.0-r1 |
| 16 |
> 4.1.0-r2 (~)1.2.4 (~)1.4.0. |
| 17 |
|
| 18 |
For example, a simple solution is to just re-number the (presumably |
| 19 |
older) 4.* as 0.4.* and be done. That would also solve the potential |
| 20 |
future problem when the latest release reaches 4.* again. The sequence |
| 21 |
I would do is: |
| 22 |
|
| 23 |
1) copy 4.1.0* to 0.4.1.0*, commit to the tree (here you could either |
| 24 |
rig the SRC_URI to keep the old tarball names, or copy the old |
| 25 |
tarballs again with the new revision number) |
| 26 |
|
| 27 |
2) Alter any packages that depend on the 4.1 versions explicitly, to |
| 28 |
depend on the 0.4.1 versions (after you're sure the new 0.4.* |
| 29 |
versions are in the tree). |
| 30 |
|
| 31 |
3) Remove the 4.1* versions - after a delay (a few days, a |
| 32 |
week, whatever, depending on how often your users are likely to |
| 33 |
update); in the changelog note that users should expect a |
| 34 |
downgrade and it is ok to do so. As a minimum, delay until |
| 35 |
you're sure (1) and (2) have reached the rsync mirrors. |
| 36 |
|
| 37 |
4) Get 1.2*, 1.4* stablilised some time later in the normal way. |
| 38 |
|
| 39 |
Actually a quick scan of the tree shows there's nothing affected by (2) |
| 40 |
so that step can be skipped. I'd recommend still having a delay between |
| 41 |
the copy (1) and the removals (3) - at least long enough for the copies |
| 42 |
to propogate to the rsync mirrors before the removals happen (I'd |
| 43 |
probably do the copy one day, check that got through ok the next day |
| 44 |
and do the removals then). Noting the expected downgrade in the |
| 45 |
changelog when the higher-numbers are removed is important (this is |
| 46 |
what users will see if they do emerge -l). |
| 47 |
|
| 48 |
-- |
| 49 |
Kevin F. Quinn |
Archives