Robert Bradshaw wrote: > On Apr 3, 2009, at 2:39 AM, Dag Sverre Seljebotn wrote: >> The question is why we have a major/minor naming scheme at all. It >> could be >> >> a) Depending on how much time's elapsed since the last major. That's >> roughly our current policy :-) > > Well, there's a strong correlation between time elapsed and new > features.
At least for 0.11, there was also a strong relation between time elapsed and size of cleanups that needed major testing and consolidation. So the above doesn't /really/ reflect our current policy. For the same reason, cython-unstable should become a major 0.xy release. It changes too many things (not break, just change) to just become a minor release. >> b) Substantial new features means new major. That's one guildeline, >> which speaks for naming this one 0.11.1. >> >> c) New major when backwards compatability is broken in any way. That's >> another, conflicting guideline, which speaks for naming this one 0.12. >> >> Myself I'm -1 on a) and +0 on b) and c). > > I'm primarily guided by (b), where "substantial new features" may > include internal re-factoring that requires lots of testing. +1, even without the "major testing" bit. Substantial code changes do not belong into a minor release. > I think > (c) is important too, but am not a stickler being pedantically strict > on this. It should be very safe to do a 0.x.y upgrade, no promises > that 0.y won't force you to change your code (for the better, though > it should be avoided--hopefully just making people remove bad/ > ambiguous/abusive code, or stuff like cdivision). That would rather speak for not making major semantic changes before 0.12. Still, I do consider the loop semantic fixes real bug fixes. The only reason to go to 0.12 right away would be to say "sorry, 0.11 was a mistake, it's dead now, please upgrade". I don't think that's true. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
