[Xfce 4.8] Improving the Release process

[Stephan Arts]

Hi guys,

While we are still waiting for the first real review of xfce 4.6, I am
thinking about ways we can improve the release-process for 4.8. The
process we went through with 4.6 was far from perfect.

The first thing that comes to mind, is a 'reasonable' release schedule
(for yet to determine amounts of 'reasonable'). To do this, we need to
establish a few guidelines for a release.

One of the problems Olivier rightfully adressed during the
release-process of xfce 4.6 was that a 2 week window between releases
is too small. By the time we release a new version, the bugreports on
the old version have just started to enter bugzilla. Then we have no
time to fix those issues and users get the impression that no progress
is being made. Both results makes you wonder why we released in the
first place. To solve this in the future, I'd like to propose a 4 week
minimum between releases.

Second, releases were delayed time and time again for several reasons.
First, we had the xfconf migration. Now, this was a big change, and it
took quite some time to get it right... so lets not make a big deal
out of that. Then, everyone had his 'pet' bug that was too important
to have in a release. By doing releases more often, 'pet' bugs should
not be an issue. By releasing Alpha's and Beta's more often, each
release is less of a milestone by itself. Making it less troublesome
to release development versions that have bugs. We sometimes seem so
committed to do 'perfect', that we are blind for the 'good enough'
state we currently have.

The advantage of a release is not the fact that people can just
download a bunch of tarballs and install them easilly without having
the need for SVN. (though that is definately not a down-side either)
They are the release-notes. A simple oversight of what we added, and
what does- and does not work. By releasing every 4 - 6 weeks, I think
we can decrease the strain we put on ourselves and the
package-maintainers. I think it would make us less likely to adopt
'pet' bugs and features, since we have another release next month.

Then we come to the labels, which indicate the maturity of the
project. We are all familiar with ALPHA, BETA and Release Candidates.
With 4.6, we did 1 ALPHA, 3 BETA's, 1 RC and 1 Final Release. All of
these were predefined. I think we can say that this did not work out
very well. As a different approach, release anyway. But if it is not
BETA quality, just release another ALPHA. Releases makes people
excited, why withold bugfixes just because we'd rather release it with
one more fix. And when we know the next release will be done next
month, and does not necessarily have to be a RC, this is not really a
big deal anylonger.

When it comes to the labels. I want to make that easy. Feature-freeze
when we start the BETA's, and String-freeze when we start doing RC's.
With a minumum 4 to 6 week period between the first RC and the final
release. I think the translators plenty of time to update their
translations.

Now, back to the 'general' release schedule... with this approach we
can not say when 4.8.0 will be ready (at least not in during the
following weeks). So it would mean going somewhat back to the 'old'
release when its ready approach. But, I believe that this way, 4.8
might be ready sooner and it will be more fun to work on the
development. (More releases, more feedback, more fun :-))

Ofcourse, I have not spoken about the things we want to change for
4.8. Like the new panel, and the menu-editor. But lets keep that aside
from this discussion for now. :-)

Regards,
Stephan