trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2014

Re: [trinity-devel] Alternative release version numbering scheme proposal

From: Calvin Morrison <mutantturkey@...>
Date: Wed, 12 Feb 2014 13:01:01 -0500
One thing to point out against Darrells points:

"NO. NO "rapid fire", "rabbit pellet" releases. This is a disaster waiting to
happen. That is the kde4, firefox, mandrake debacle all over again."

Look at LibreOffice. Before there were almost NEVER releases with
OO.org, but libreoffice continually chugs away at new releases, every
4 months I think. That way I am constantly getting the improvements
over time. If we don't release often enough, what happens is that
people will just start using the nightly-builds more. That is why it's
important to have seperate development branches.

For example, LO has a stable branch, and does bugfix releases on
it(akin to  TDE 3.5.X i guess), and continues to push new changes to
their new branch.

Now why faster releases are good:

Faster releases also means bugfixes go out faster to users, not
waiting 2 years to get a small fix for something simple like a
konqueror loading error.

Enough drops in the bucket and you end up with a bucket full. You guys
are working hard on bug patches, so the sooner they get out to users
the better the project will appear to end users, and the happier they
will be.

What it really adds up to is an insane amount of discipline when it
comes to GIT, doing all new features in a seperate branch for example,
keeping master very stable, and merging those new features in only
during preperation for a release period. There are a plethora of ideas
on how to properly use version control, but that is one way I can
think of to have users getting good fixes frequently, and new features
less often (but only after they're stable)

I think like everything, moderation is good. There's always the tug
and pull or wanting to get users fixes, but not wanting to screw
anything up

Sorry for my long winded speech

Calvin