[pypy-dev] Naming scheme

Gasper Zejn zejn at kiberpipa.org
Thu Apr 16 23:31:09 CEST 2009


On Thursday 16 April 2009 22:36:34 holger krekel wrote:
> On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
> > 2009/4/16 holger krekel <holger at merlinux.eu>:
> > > Hi Maciej,
> > >
> > > On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
> > >> Hello.
> > >>
> > >> That might sound a bit like bike sheding, but I would like to talk a
> > >> bit about naming scheme.
> > >>
> > >> What do you think about actually naming PyPy release 2.5 after
> > >> language version it supports?
> > >>
> > >> We can invent suffixes like pypy-2.5-something in order to release
> > >> still 2.5, but which supports some more
> > >> things (like JIT?).
> > >
> > > i think that PyPy's advances are not too much related to
> > > language compat issues but rather to better GCs, stackless,
> > > JITting, optimisations, etc.  So i don't see the language
> > > compat as the central theme.
> >
> > But to users of Python on PyPy, the corresponding CPython version is
> > more important than say a new GC. Perhaps there should be two
> > versions?
>
> We are still doing a source-release, though.
> Maybe a name like "pypy-c-2.5-1.1" for the generated
> and compiled Python interpreter would make sense?
> That would also likely be the one that people see
> once it e.g. gets packaged in debian.
>
> best,
> holger
>

I don't think features of a release should go into version number, they can go 
to release code name, but that's more of a marketing plan than a matter of 
versioning in my opinion. I'd go with something along 

pypy-1.1-cpython2.5
pypy2.5-1.1

which I think is very informative about both the syntax and CPython features 
compatibility and also PyPy version. Of course, release notes should 
generously explain main features and also CPython compatibility.

Regards,
Gasper Zejn




More information about the Pypy-dev mailing list