[Bf-committers] Avoiding regressions, changes to the release cycle.

[Campbell Barton]

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.