Replying to most of the replies to this thread...
@Jürgen Herrmann, re: 3 month releases, We can of course change release schedule however we want, my point was mainly that I think it wont make blender more stable on its own, if we want to change release schedule for other reasons then stability, then thats a different discussion. @Thomas Dinges, re: not having to do six releases a year, Sure, we can manage this how we like - but I think the iterations enforce us to keep blender stable and make sure we are good at doing releases. re: not make this "review changes more thoroughly" an optional thing (Brecht also echoed this sentiment) There are some fixes that really are simple - a poll function missing a NULL check for example. We can define that there are no simple fixes and all fixes get reviewed after RC/bcon4-whatever..., I'm OK with that but we have some history with defining strict rules and then not following them so I'm hesitant to push for larger changes that end up getting ignored :S. My main concern is that we accept risky commits after the final RC, just because they contain the word fix in the commit log, The details of how to determine whats a risky change I'm sure we can agree on later. @Thomas Dinges, re: Middle of bcon4 do and RC, then Sounds good to me. @Jürgen Herrmann & @Constantin Rahn re: there should be no changes after an RC We currently mis-use the term RC for beta/pre-release (by definition our RC's are not candidates for a release), I've pointed this out many times before but Ton still like to call it an RC, not sure if this is because English isn't his first language or if calling an RC is wishful thinking. At some point I gave up discussing this topic, you make a valid point. @Joseph Mansfield re: SVN hook that reports the current BCon level Perhaps we could include bcon level in splash, not sure this is really needed though. @Brecht re: branching stable (keeping trunk for development) This topic has come up before, IIRC Ton is against doing this since it means developers focus less on stabilizing and users who build are less likely to update svn and use the version of blender we will release (valid points IMHO). If we rename our 'release' -> 'RC', and '2.68a' -> 'release', then this is exactly what we do already (since the bugfix release is made from a tag of trunk). Though I worry too many issues get conflated and then we don't agree on basics. re: Simple fixes I should have been more clear that the simple fixes would be for crashes - basic crash on NULL pointer de-references for eg, If they open up a can of worms or require changes to many areas - then they are not simple fixes. Anyway - if they are really that simple I guess having to review should also be simple so we can agree to review all changes after an RC. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
