On Mon, Jan 26, 2009 at 06:05:42PM +1300, Laszlo (Laca) Peter wrote: > > > This project delivers Python 2.6 and 3.0 into Solaris. Python 2.4 > > > and Python 2.5 are now Obsolete. > > > > This seems an awfully sudden jump from working Python to 'you need to > > port all your code to Python 2.6'. I don't recall offhand how serious > > the incompatibilities are between 2.6 and earlier? > > The reason why we'd like projects to move away from 2.4 is so that > we only need to have 1 version of Python on the OpenSolaris LiveCD, > where space is limited. Some parts of the next version of GNOME will > need at least 2.5. We will move to 2.6, but we will also need to > have 2.4 on the LiveCD until IPS moved to 2.6 too.
Seems like a good reason to start the process for obsoleting 2.4 now, and *possibly* 2.5. But I don't think you can reasonably immediately obsolete 2.4 without any previous warning. BTW 'Obsolete' is a modifier not a classification, see the interface taxonomy. Since 2.4/5 are uncommitted, this allows you in theory to remove them in the next build. This can't be right. > > > Projects delivering Python modules are required to deliver them > > > for all non-Obsolete versions of Python that are shipped on the > > > system. New projects do not have to deliver Python modules for > > > Obsolete versions, but existing modules must be delivered for > > > all versions. > > > > Surely 2.4/5 should be going through a longer period of obsolesence > > rather than just disappearing at any point from now. There's a lot of > > Python code out there. > > It's not going to disappear any time soon, in fact we have no plan to > make it disappear. At the very least, it should remain in the IPS > repository since, as you say, there's a lot of Python code out there. > The reason for declaring it Obsolete is to signal that new projects > should not target 2.4 or 2.5 and to ease the requirement of delivering > all python modules for 3 different versions (and possibly multiplied > by 2 ISA variants). I would have expected to see something like: - mark 2.4 as Obsolete Uncommitted, with some indication in the case about following a notification period, instead of immediate removal I guess your comment above will do this - keep 2.5 in its current state - new code must deliver to 2.5 and 2.6, but not 2.4 OR - make 2.5 be like 2.4 - new code must deliver to 2.6, but not 2.4 or 2.5 This would depend on if 2.6 is really incompatible. I couldn't find any clear statement on incompatibilities, and if they're considered bugs or not. Do we have an idea? - code may deliver to 3.0 if upstream has a version As Rich Lowe pointed out, you're now requiring that any new Python code deliver for both 2.6 and 3.0. Given that would require permanently forking the upstream codebase, this seems rather onerous! Perhaps I'm really arguing that Python being Uncommitted no longer reflects the reality of the situation. regards john
