Hi Rami, On Fri, Nov 29, 2013 at 8:20 PM, Rami Chowdhury <rami.chowdhury@gmail.com> wrote:

What would this involve? I ask not only for my benefit but also for any other newbies that may be lurking here and thinking about getting involved :-)

http://doc.pypy.org/en/latest/how-to-release.html A bientôt, Armin.

On 02/12/13 21:08, Philip Jenvey wrote:

It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?

Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple < (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.

another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles. I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number > (2, 2).

On 12/03/2013 03:42 AM Philip Jenvey wrote:

On Dec 2, 2013, at 3:13 PM, Antonio Cuni wrote:

...

On 02/12/13 21:08, Philip Jenvey wrote:

...

It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?

Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple< (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.

another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles.

For this particular issue the suffix could be 'pypy3' instead. Though this is not ideal, should 'PyPy3' be reflected in sys.version, sys._mercurial[0], platform.python_implementation(), etc?

...

I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number> (2, 2).

This would be weird but I don't think it would break any version number checks, being a higher number.

-- Philip Jenvey

Just a thought: If you consider that pypy is an alternate *implementation* of the python lanaguage, ISTM the implementation should do whatever the version of the python *language* implies (2.7.3 as of now?). The version of the implementation (pypy or other) would seem to be orthogonal. No? Regards, Bengt Richter

Hi Rami, On Fri, Nov 29, 2013 at 8:20 PM, Rami Chowdhury <rami.chowdhury@gmail.com> wrote:

What would this involve? I ask not only for my benefit but also for any other newbies that may be lurking here and thinking about getting involved :-)

http://doc.pypy.org/en/latest/how-to-release.html A bientôt, Armin.

On 02/12/13 21:08, Philip Jenvey wrote:

It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?

Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple < (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.

another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles. I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number > (2, 2).

On 12/03/2013 03:42 AM Philip Jenvey wrote:

On Dec 2, 2013, at 3:13 PM, Antonio Cuni wrote:

...

On 02/12/13 21:08, Philip Jenvey wrote:

...

It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at least for now, since it implies the release schedules are tied together. Maybe they should be though?

Calling it PyPy3 w/ the same version scheme seemed to make the most sense vs the other options. A PyPy3 v0.1 could have broken some cases of code like sys.pypy_version_tuple< (1, 5) in the wild. Calling it PyPy 3.0 would have made sense but forced the CPython 2.7 compat. PyPy stick with a 2.x scheme forever.

another issue is with cpyext: if sys.pypy_version_number is the same, pypy3 extension modules will have the same .pypy-22.so extension as the pypy2 version, causing potentially lots of troubles.

For this particular issue the suffix could be 'pypy3' instead. Though this is not ideal, should 'PyPy3' be reflected in sys.version, sys._mercurial[0], platform.python_implementation(), etc?

...

I cannot think of a good way to solve the problem though. One possibility is to have pypy_version_number incremented by 3000, so that this would be PyPy 30002.2. Note that this would still break code like pypy_version_number> (2, 2).

This would be weird but I don't think it would break any version number checks, being a higher number.

-- Philip Jenvey

Just a thought: If you consider that pypy is an alternate *implementation* of the python lanaguage, ISTM the implementation should do whatever the version of the python *language* implies (2.7.3 as of now?). The version of the implementation (pypy or other) would seem to be orthogonal. No? Regards, Bengt Richter