Messages in this thread | | | Date | Sun, 20 Jul 2008 01:10:48 +0200 | From | "Peter T. Breuer" <> | Subject | Re: From 2.4 to 2.6 to 2.7? |
| |
Craig Milo Rogers <rogers@isi.edu> wrote: >> rename 2.6.28 to 2.8.0 >> or >> rename 2.6.29 to 2.9.0 >> or >> rename 2.6.30 to 3.0.0 >> >> i.e. .. whatever you are doing now, just drop the first two numbers (the >> "2.6" bit) since they seem to be constant.
> So you're saying that the formula is to drop the "2.6" and place > a period between the first and sedond digits of what's currently the > release number? OK, I hadn't interpreted it that way. Does the sequence > continue like this?
The point is to rebase to a new system at a point coming up which is convenient. There is an opportunity at 2.6.28, which can be renamed 2.8.0, dropping the constant 2.6.
I suppose one counts 2.8.1, 2.8.2 from then on, or does whatever else one wants to do. I don't know - Linus' only objective is to get smaller more meaningful numbers and the details of how one counts afterwards don't matter.
Or if one misses the 2.6.28 point, one gets another good opportunity for rebasing at 2.6.30, which could become 3.0.0, dropping the constant 2.6 again.
>> Remember that Linus' only objective is to have smaller numbers, which >> may therefore >> >> 1) be memorable >> 2) be good advertising copy >> 3) be meaningful >> >> and that was the only intention of my scheme: "drop the constant bit".
> And the underlying problem is that there are only so many > small numbers.
We need smaller numbers now.
I.e. We're happy with the system we've got, except for the high numbers we're at, so just rebase.
Peter
| |