[arch-dev-public] Transitioning between incompatible language versions

[Dave Reisner]

On Tue, Sep 18, 2012 at 10:10 PM, Allan McRae <allan at archlinux.org> wrote:

> Hi,
>
> The recent lua-5.2 thread and also python-3 have highlighted the need
> for us to really have a policy for how we deal with providing two
> different versions of a language interpreter in the repos.  This is
> particularly important when there is a period of time where we want to
> supply the newer version of the language, but much software has not
> transitioned to it yet so we must provide an old version too.  Note I
> while i am specifically considering programming languages here, this
> could apply to libraries as well where we are force to provide an old
> version for some time.
>
>
> There are two options that I see (assuming that us being Arch Linux
> always want the newest version in the repos...)
>
>
> 1) The "foo" package is the newest version of the language and the
> legacy version gets the version attached to it - i.e. "foo1".
> Libraries for the language "foo" would be called "foo-libname" and
> "foo1-libname"
>
> 2) Both packages have a version attached to their name.  "foo2" and
> "foo1". Libraries for the language would be called "foo2-libname" and
> "foo1-libname"
>
>
> Choosing which version:
>
> #1 is best if we expect all software to be updated to the new version
> and the legacy version to be soon removed  (e.g. for lua?).
>
> #2 is best if we think we will continue to support both versions for an
> extended period of time (e.g. python2/3).
>

As long as we all agree that python should have been python3 ;)


> Does that sound a reasonable policy?   It would be up to the maintainer
> to decide whether to use naming scheme #1 or #2 based on expectations of
> the language's future.
>

Sure, this sounds reasonable to me. Maintainers just need to remember that
the decision for legacy support should be strongly driven by the upstream
future of the language -- e.g. Python2 will see fixes through 2015, but
lua51 is being phased out on a much shorter timeline. There's also
availability and ABI/API concerns that need to play into this. Of course,
I'd hope that the upstream drives their support decision with this in mind,
so this element of the decision shouldn't be too much of a concern for us
downstream.


> Comments?  I'd like to get this sorted quickly so we can get the python
> and lua rebuilds done.