Hi Everyone,
I'd like to propose a new set of rapid-release milestones for the
Compiz project over the next few months for the upcoming 0.9.6
release. The reason I'm doing this is to create a more stable
environment for prospective contributors and a more stable environment
to work from for distribution packagers. Our current model in the 0.9
series of "release when its ready" isn't working out for us because of
the rolling nature of the way bugs are being fixed and features are
being added. With a structure which focuses on a series of smaller
milestones we'll be able to better priorities what we want to do and
give ourselves more time to maintain those fixes and make sure there
aren't any regressions.
So without waffling on too much further, here are the dates and
release version numbers I'd like to propose. If nobody has any serious
objections to these dates, I'd like to set them and stone and move on
from there since the dates aren't really as important as the
procedure:
0.9.5.0 - 12 July 2011
0.9.5.2 - 26th July 2011
0.9.5.90 (beta1) - 09 August 2011 - FEATURE FREEZE
0.9.5.92 (beta2) - 30 August 2011
0.9.5.94 (rc1) - 13 September 2011
0.9.5.96 (rc2) - 20 September 2011
0.9.5.6 (final) - 27th September 2011
0.9.5.7 - 11th October 2011 (All new features get merged in)
The point is with these milestones that the most disruptive changes go
in at the beginning of the major cycle and don't go in at the end of
it. Which means that changes which are more likely to have
far-reaching effects are not going to be merged in when we're in a
critical area. So, eg, we're not going to allow features past feature
freeze, bugfixes which change a lot of code past beta2 are not going
to go into that release series etc. I'd also like to target particular
bugs for releases so that people know what the priorities of the
project are and what people can help out with if they're interested in
helping out.
For each subcycle, I'd like to propose something similar to the following:
First of all, we make a git branch for that release series, eg
compiz-0.9.5.0 . All work for that subcycle happens in master, which means
that people who prefer to run from git can just checkout the latest
micro release
branch (we can consider whether to make this the default ref) and aren't
potentially running broken code.
First 5 days of the cycle are when features and bugfixes for targeted
things get merged in. Ideally those will be going through a pre-commit
code review, but I think that for now we will just allow people to
commit to a series and revert their commits if they are causing
problems or don't make sense (obviously with explanation of *why* that
happened which would be very very very rare, because ideally we'd have
enough time to fix problems before the target). Then we open a call
for testing on that series and fix the problems that those merged in
fixes or features are causing or revert them if they are causing too
many problems. By the next 5 days, we do a release, merge that branch
into master, tag it, do the release mail and open the next sub-cycle
series.
This has the run-on effect of encouraging people who are doing big
items of work to work in separate branches, polish their features or
bugfixes and then merge it in on each sub-cycle merge window, rather
than working directly on master.
As for the infrastructure work, I've recently merged in the cmake work necessary
to make releasing as easy as possible, now every single module has a VERSION
file and can also be built with CMake and every single module has the
following targets:
* release-prep: updates AUTHORS, ChangeLog, NEWS
* distcheck: creates a .tar.bz2 archive of the current HEAD which can be sent
out for testing during the call for testing of the release, builds it, runs
make test (for unit tests)
* release-signoff: applies the changes to AUTHORS, ChangeLog, NEWS to HEAD,
and commits them, tags this commit as the "compiz-${VERSION}" release, creates
a branch from this commit called "compiz-${VERSION}-series",
creates a file called RELEASED with the contents of VERSION, commits that,
re-creates the tarball of HEAD, asks for a new VERSION, signs and
sha1's the tarball
* release-push: actually pushes the created branches, tags and objects
to the upstream git repository
* release-upload: actually uploads the signed tarball to releases.compiz.org
Obviously, release-push and release-signoff can't just be run by
anybody, you must have access to releases.compiz.org and
git.compiz.org and the repo in order to use it.
If nobody has any objections to this, then I'd like to set the date
for the next release to be 12 July 2011 and consider this process to
be effective from that date
Regards,
Sam
--
Sam Spilsbury
_______________________________________________
dev mailing list
[email protected]
http://lists.compiz.org/mailman/listinfo/dev
