[Bf-committers] Avoiding regressions, changes to the release cycle.
ideasman42 at gmail.com
Tue Jul 30 11:25:17 CEST 2013
Replying to most of the replies to this thread...
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.
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
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.
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.
re: SVN hook that reports the current BCon level
Perhaps we could include bcon level in splash, not sure this is really
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
More information about the Bf-committers