On Fri, 2008-08-22 at 17:15 -0700, Danek Duvall wrote: > Given that Python 2.6 just hit its final beta, wouldn't it make sense to > target that instead? Or is 2.5 all ready to go pending this ARC case, > while 2.6 would take another couple months to wait for release, complete > testing, etc?
That's exactly the case. 2.5 is read to go and can be integrated into [Open]Solaris in time for the next OpenSolaris release. I haven't started to port all the source patches to 2.6 yet. > > Projects delivering Python modules are advised to deliver them > > for both Python 2.4 and Python 2.5. > > Is there a requirement to deliver them for one version or the other? If > "both" is merely advisory, then one team may deliver for one version, > another for the other version, and anyone wanting to use those modules will > be unable to use both. > > Perhaps there should be a requirement for 2.5 modules? Or just make both > required for the time being? That would make sense, at least until 2.4 is Obsolete, but I'm not sure how to enforce it. For the modules delivered by the Desktop team (probably most of them), I'll make sure they are delivered for both versions. > > Projects delivering shared object Python modules are advised to > > deliver both 32 and 64-bit versions, as per PSARC/2006/666 > > Same issue here, too. Though the way this is worded suggests that the word > "shared" is missing from the 2.4/2.5 paragraph. This is a bit different issue. Essentially, all Python modules should have 4 variants: 2.4 32-bit, 2.5 32-bit, 2.4 64-bit, 2.5 64-bit. (In the case of pure python modules the ISA doesn't matter.) > Projects delivering > Project Private modules can presumably do whatever they want. Right. Thanks for the comments, Laca
