On Mar 12, 2009, at 2:43 AM, Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: >> 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. >> > That's my concern too.
We don't have this issue with Sage as we ship Cython as a component. (We even ship and build our own Python...) However, modulo any bug fixes, I think the 0.x range should all be compatible. >> 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. >> > +1 to cython-devel and cython-unstable. Yes, I'll make such branches. I like the idea of "safe" stuff (either fixes or minor improvements) being in cython-devel, and anything more drastic (e.g. moving all the temp stuff over to the new model) in cython-unstable. A much better division than "bugfix" and "other." - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
