| 1 |
On Wed, Nov 18, 2015 at 10:10 AM, Brian Dolbec <dolsen@g.o> wrote: |
| 2 |
> On Wed, 18 Nov 2015 06:59:19 -0500 |
| 3 |
> Rich Freeman <rich0@g.o> wrote: |
| 4 |
> |
| 5 |
>> Actually, what is less clear to me is how portage versioning actually |
| 6 |
>> works, or if we attach any meaning to the version numbers at all. |
| 7 |
>> Both the stable and unstable series are on 2.2.x, but there are no |
| 8 |
>> versions in the tree between 2.2.20 and 2.2.23. |
| 9 |
>> |
| 10 |
> |
| 11 |
> So, we have 2 user groups, stable and unstable. |
| 12 |
> |
| 13 |
> Current stable is 2.2.20.1 |
| 14 |
> current unstable is 2.2.25 <==just released |
| 15 |
|
| 16 |
So, my first point was that the version numbering seems to have no |
| 17 |
relationship to what is stable and unstable. It isn't really meant as |
| 18 |
a big complaint, but it just suggests a lack of a release strategy. |
| 19 |
|
| 20 |
> |
| 21 |
> With 2.2.4 becoming stable, why would we keep the buggy ~ 2.2.3 in the |
| 22 |
> tree taking up space? We already established that ~ users will have |
| 23 |
> migrated away from it. |
| 24 |
> |
| 25 |
|
| 26 |
Sure, and my comment wasn't really directed at portage in particular, |
| 27 |
though it is a fair reply because I did use it as an example. Portage |
| 28 |
is a bit unique in that it has no upstream QA process - the QA is |
| 29 |
being done entirely within Gentoo. For packages other than portage |
| 30 |
there should be less reason to drop versions, since they probably |
| 31 |
wouldn't have been released if they were unsuitable to release. |
| 32 |
|
| 33 |
> |
| 34 |
>> That tends |
| 35 |
>> to result in a situation where if you follow ~arch you end up having |
| 36 |
>> to accept lots of updates because none of the versions stay in the |
| 37 |
>> tree long enough to actually get stabilized. |
| 38 |
> |
| 39 |
> that happens for some pkgs, if it happens too much for you, update less |
| 40 |
> often. |
| 41 |
|
| 42 |
What do you mean by "update less often?" Are you suggesting not |
| 43 |
running emerge --sync? Not wanting to follow every ~arch version of a |
| 44 |
package whose stable version has a problem isn't the same as not |
| 45 |
wanting to update your entire tree, and there is no reason to force |
| 46 |
users to choose between only those choices. |
| 47 |
|
| 48 |
> |
| 49 |
>> Unless a ~arch package |
| 50 |
>> version is so broken that it could never be stabilized it is probably |
| 51 |
>> better to leave them there so that it is easier for users to drop back |
| 52 |
>> from ~arch to stable without downgrading. |
| 53 |
>> |
| 54 |
> |
| 55 |
> Rich, please re-read your above statements until you see the total |
| 56 |
> failure in your logic. |
| 57 |
|
| 58 |
It is a bit ironic that you chose this as the part to quote when |
| 59 |
adding a snide remark. My whole point was that we shouldn't |
| 60 |
NEEDLESSLY drop old versions, You seemed to have taken this as a |
| 61 |
complaint about dropping old versions when there is a valid reason for |
| 62 |
doing so. |
| 63 |
|
| 64 |
Your tone here is anything but helpful. My intent was really to |
| 65 |
contribute to the discussion constructively and point out a pain point |
| 66 |
for people running mixed-keywords. Perhaps I didn't explain my point |
| 67 |
as well as I could have. When somebody is saying something that |
| 68 |
doesn't seem sensible to you, it is usually better to assume that they |
| 69 |
just didn't make their point well than to assume that they don't have |
| 70 |
anything worth saying. |
| 71 |
|
| 72 |
-- |
| 73 |
Rich |
Archives