Robert Bradshaw wrote: > On Mar 12, 2009, at 12:12 AM, Dag Sverre Seljebotn wrote: >> Could we also put in something about which repositories to use for the >> various releases? I.e. some questions: >> >> - Will we use cython-devel or cython for 0.11.1? >> - If I do something that's just cleanup and not bugfix (e.g. convert >> NameNode to new temps), should that go into 0.12 or 0.11.1?
Depends on how much we break with it. ;) >> I'm in favor of 0.11.x going in cython and NOT contain cleanup, only >> bugfixes, but I'm really OK with either. > > I'm actually not a huge fan of bugfix-only releases being parallel > with main releases ... also because it already happened that we forgot to push a fix into "cython". That said, it's sometimes easier to put trivial fixes into cython and pulling them over. > --I'd rather get the new features out as soon as > possible too. I am willing to try that approach for this next release > cycle if people things it's a good idea though. (That being said, I > do like to be relatively "safe" with minor releases.) > > 0.11.1 should be the low-hanging fruit, e.g. some of the stuff that's > already been implemented but didn't make it in in time. +1 and I think we should actively use trac's milestones to decide which fixes and features go where. However, the above doesn't answer the question if we should distinguish between potentially dangerous changes (that we implement because we can or because we need them, and have to put somewhere) and those that are safe enough to go into the next release. I would like to have something like a stable release series of Cython that other projects could depend on. I was having a pretty hard time in the past telling people that they must build lxml with /this/ Cython version instead of /that/ one. Being able to hold certain changes back will definitely help us in getting releases out a lot faster than 0.11. What about a separate cython-0.12 branch only for non-0.11 changes, next to a 'somewhat' safe cython-devel? When a major change is required, we can push it there instead of cython-devel, start working on it and have others test it while we can still release 0.11.x from cython-devel. It doesn't need to be up-to-date with cython-devel all the time (just when we push changes), and we can always import certain changes into cython-devel if we think we can't wait for 0.12. Or maybe "cython-unstable" would be a more generic name. Also, it would be good to pile up a set of test projects (sage and lxml as we do now, but also some others) that we regularly test before any release. Sort of a continuous integration test setup, like Python's buildbots. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
