"Maciej (Matchek) Bliziński" <[email protected]> writes: > 2013/7/22 Peter FELECAN <[email protected]>: >> Do you mind committing the patch that you proposed in [1] with the >> exception of different naming schemes for 2.7, i.e. no CSWpy27- prefix? > > The naming remains a problem, if we want to share modules between 2.6 > and 2.7, we need to do something similar to what Debian did.
Lets do it Debian way. Always a good reference, as you already mentioned: http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html >> What about CSWpython27 and co: do yo release them? > > I've switched both Python versions to alternatives, so we're ready to > release them. The main problem to solve is how do we share modules > between 2.6 and 2.7. My question is: do you release 2.7? > As to why 2.6 code wouldn't work in 2.7 ‒ Python 2.7 is meant to be > backwards compatible, so there isn't an obvious example. In a perfect > world you'd just flip the switch, but in reality you cannot migrate > your production over to 2.7 without prior testing and a migration > procedure. The migration procedure would include changing > #!/opt/csw/bin/python2.6 to #!/opt/csw/bin/python2.7. From my point of view this is not very convincing but you're the Python Czar consequently bowing to it. > In short, you cannot make our users run 2.7 on our call. They need to > switch to 2.7 at their own schedule, and we need to make it very clear > about when we're pulling the plug on 2.6. The moment of switch will be when this unstable becomes a named version, i.e. stable. However, nothing precludes to still have legacy 2.6 modules in it. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
