On Tuesday 09 April 2002 02:44 pm, Jacob Hallén wrote: ...

I would also like to add that there is a benefit with the multiple numbering scheme. The various distribution makers will most probably build packages for both the stable and the experimental versions, allowing people to easily maintain both versions on their machines. With the current situation, most distribution builders will skip the alpha, beta and rc versions, thus decreasing the population that will actually test them.

I suspect the situation may change by distribution. Mandrake, if I know them well (and I'm a satisfied customer for over a year, supporting member of the Mandrake club, etc), WILL keep on top of the bleeding edge, releasing a stable-python and an experimental-python package, or something like that -- they know their customer base includes a lot of rabid neophiles, as well as people who only want stability. Debian, though, I wonder -- I doubt they'll put in their "Stable" distribution anything not vouchsafed for by Methushelah in person:-). As for RedHat, no problem -- they'll keep shipping 1.5.2 anyway...!-) Alex

Hi Jacob!

I would also like to add that there is a benefit with the multiple numbering scheme. The various distribution makers will most probably build packages for both the stable and the experimental versions, allowing people to easily maintain both versions on their machines. [...]

We are already doing this here. We have 2.1 packaged as an alternative package for 2.2, and they can be installed at the same time. OTOH, 2.2 is the main package, since it's passed the updates we've done in the various systems without any problem. 2.1 is not being distributed right now, because of that (even though we have the package, and use in some clients with Zope and alike). I wouldn't like to be forced to package 2.1 as the main stream package, because 2.2 is tagged as "unstable" (or "in-development", or whatever).

With the current situation, most distribution builders will skip the alpha, beta and rc versions, thus decreasing the population that will actually test them.

The problem is not about the naming scheme ("alpha", "beta", etc), but its stability. I'm not going to include Python in an alpha stage, no matter how it's named. OTOH, I'd include an rc version as we know today, if the deadline obligate me to. Even with all these discussions, I don't have a favorable position to the change yet. That's probably because I've always had a terrible impression about the Linux release scheme. With API breaks at anytime and releases that just don't compile, I'd say Linux has two branches, UNSTABLE and VERY-UNSTABLE. At the same time, I've always had the python release scheme as a well designed one. I don't think changing it will help Python. Indeed, it may even help those missinformed heads create more confusion, and consume the already rare time of core developers. Best regards! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

On Tuesday 09 April 2002 02:44 pm, Jacob Hallén wrote: ...

I would also like to add that there is a benefit with the multiple numbering scheme. The various distribution makers will most probably build packages for both the stable and the experimental versions, allowing people to easily maintain both versions on their machines. With the current situation, most distribution builders will skip the alpha, beta and rc versions, thus decreasing the population that will actually test them.

I suspect the situation may change by distribution. Mandrake, if I know them well (and I'm a satisfied customer for over a year, supporting member of the Mandrake club, etc), WILL keep on top of the bleeding edge, releasing a stable-python and an experimental-python package, or something like that -- they know their customer base includes a lot of rabid neophiles, as well as people who only want stability. Debian, though, I wonder -- I doubt they'll put in their "Stable" distribution anything not vouchsafed for by Methushelah in person:-). As for RedHat, no problem -- they'll keep shipping 1.5.2 anyway...!-) Alex

Hi Jacob!

I would also like to add that there is a benefit with the multiple numbering scheme. The various distribution makers will most probably build packages for both the stable and the experimental versions, allowing people to easily maintain both versions on their machines. [...]

We are already doing this here. We have 2.1 packaged as an alternative package for 2.2, and they can be installed at the same time. OTOH, 2.2 is the main package, since it's passed the updates we've done in the various systems without any problem. 2.1 is not being distributed right now, because of that (even though we have the package, and use in some clients with Zope and alike). I wouldn't like to be forced to package 2.1 as the main stream package, because 2.2 is tagged as "unstable" (or "in-development", or whatever).

With the current situation, most distribution builders will skip the alpha, beta and rc versions, thus decreasing the population that will actually test them.

The problem is not about the naming scheme ("alpha", "beta", etc), but its stability. I'm not going to include Python in an alpha stage, no matter how it's named. OTOH, I'd include an rc version as we know today, if the deadline obligate me to. Even with all these discussions, I don't have a favorable position to the change yet. That's probably because I've always had a terrible impression about the Linux release scheme. With API breaks at anytime and releases that just don't compile, I'd say Linux has two branches, UNSTABLE and VERY-UNSTABLE. At the same time, I've always had the python release scheme as a well designed one. I don't think changing it will help Python. Indeed, it may even help those missinformed heads create more confusion, and consume the already rare time of core developers. Best regards! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]