2013/7/19 Peter FELECAN <[email protected]> > (snip) > 3. 2.7 becomes the default python for our distribution, thus new > packages depends on it and the gar python recipe adapts to this but > using CSWpy- prefix; I'm hesitating to add that we can obsolete > CSWpython-xxx by CSWpython27-xxx
I can imagine the following scenario: User: I upgraded CSW stuff and my application is not working, it fails with "ImportError: No module named foo" Us: Which Python are you using? User: Python 2.6 Us: We made Python 2.7 the default and we're removing Python 2.6 support. User: But my application requires Python 2.6. Us: Then update your application. User: It's a third party application, we cannot modify it. > 4. when version bumps are committed for existing packages, the transition > is implicit > > 5. when there is an issue with an existing package, built using 2.6 with > unversioned tree, we re-spin it; this is why we have Mantis isn't it; > I think that a Python working group can be created to take into > account packages for retired maintainers. > > What do you think? We might make Python 2.7 the default but it doesn't mean that our users will. I vote for not breaking Python 2.6 for our users. Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
