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

[Sébastien Luttringer]

On Wed, Sep 19, 2012 at 4:10 AM, Allan McRae <allan at archlinux.org> wrote:
> Comments?  I'd like to get this sorted quickly so we can get the python
> and lua rebuilds done.

My suggestion would be to simplify the both case into the first.
Simpler is the policy, easier is to apply.

Here we make 2 cases based on lua and python upstream behaviour.
- python: Hardly break compatibility with long support for old version
leading to a slow move of libraries and programs.
- lua: Lightly break compatibily with short support for old version,
leading to a fast move of libraries and programs.

If we look closer at what python upstream do, they break compatibily
even in minor version update. Not deeper as with 3.x bump, but some
API are removed after a time of deprecation. This funny guy give some
examples of incompatibilies ("with" becoming a keyword, raise of
strings become forbidden) between python 2.4 and python 2.6 (despite
the title of his article and what he claims) [1].

So we doesn't want have python2.4-foo and python2.6-foo because we
think that library must follow upstream for small breakage and we want
avoid maintaining λ versions in parallel.

I'm not medium but upstream probably learn from this difficult move
from python2 to python3 and If python3.X->python4.0 is not a big
breaking like python2.7->python3.0 we don't want to rebuild all
package with deps and rename all libraries. Same games for all others
languages (lua, perl, ruby).

So dropping old versions of a language is always dependents of:
- upstream support ;
- first class library moves ;
- big software doesn't require it.

About python I suggest to keep python-foo and python2-foo as long as needed.
If python4 pop-up without breaking compatibilty python3-x will never
be required as update will be smooth.
If python4 break everything, we can have python-foo, python3-foo and
python2-foo.

Same idea for lua. So one case will suffice.

About prefix of libraries I would suggest to don't be too strict in
package naming and don't be redundant when a package name start by our
prefix. It's a common case for languages libraries (e.g: luaposix[2],
luafilesystem[3], pyqt[4], ruby-gnome2[5]).
Do we want ruby-gnome become ruby-ruby-gnome2 package? Answer is
probably here [6].
If our prefix is choucroute- and project name is choucrouteroxx,
choucroute-roxx is smarter than choucroute-choucrouterox?

Cheers,

[1] http://regebro.wordpress.com/2010/02/12/yes-python-2-6-is-backwards-compatible/
[2] http://luaforge.net/projects/luaposix/
[3] http://keplerproject.github.com/luafilesystem/
[4] http://www.riverbankcomputing.co.uk/software/pyqt/intro
[5] http://ruby-gnome2.sourceforge.jp/
[6] https://www.archlinux.org/packages/community/i686/ruby-gtk2/

-- 
Sébastien "Seblu" Luttringer
www.seblu.net