[Bf-committers] Status of 2.35a/b

[Bert Driehuis]

On Thu, 25 Nov 2004, trip wrote:

> Aw... That then removes the constant 'fun' at testing out new features
> in beta mode as much. What about two different forks one for beta one
> for super non buggy like someone mentioned before. That way fun could
> still be had but you also keep blenders good name sake to outsiders.

It is my experience that this works only if you have a really dedicated
release manager (dedicated as in: will spend _a lot_ of time keeping
code in sync and developers in check).

Moving patches between branches may sound easy, but as soon as the first
non-bugfix code rewrite goes in things will start to go downhill, and
with most projects that happens days after the release.

In a project I'm rather intimately involved with, my assertions to this
effect have been regularly challenged, but offering to promote that
person to "release coordinator" seems to take the wind out of the
challenges.

IMHO, a code freeze is the best way to deal with a release, because even
if you have the time to maintain multiple branches, chances are you
could spend that time more wisely coding up stuff or squashing bugs.

In response to Ton's original concern, bumping the minor version is
probably wise if any code changes were needed after initial release.
Just about the only situation that I'd use a micro revision letter is
when an error in packaging occurred. And even then you may pay dearly
for it. It is just incredible how many users will hold on to a
mispackaged copy and then start mailing you about how the installation
is broken.

Cheers,

				-- Bert

-- 
Bert Driehuis -- driehuis at playbeing.org -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!