As you know we've recently spinned our 1.0 branch off of trunk. While
preparing the 1.0 to trunk merges and the 1.0 nightlies we've had a few
off-list discussions (with some of you) on how exactly we should be
handling this release and the following updates that would reflect bug
fixes and other patches.
The initial plan was to go through several release candidates, then
release 1.0.0, then continue with 1.0.x releases until we decide to
discontinue the branch.
The thing is that this way we are adding a lot of release management
overhead without any substantial benefit.
I am therefore suggesting that we handle things the following way:
The first nightly build over the 1.0 branch is to be considered our 1.0
release. This is obviously not going to be THE stable release since
there are still a number of known issues that would get fixed with
subsequent releases. This means that we won't have to announce this
release with all the fanfare typical for a first roll out. All following
commits would then trigger 1.0.x releases. One day, when and if we
manage to fix all pending 1.0 issues we may want to drop a few
announcements here and there notifying the world of our first officially
stable release. If this doesn't happen with 1.0 it would with 2.0.
All auto update mechanisms that we currently support (debian, sparkle,
rpm, and our home grown windows updater) would be working independently
over the two build lines.
We are going to continue maintaining the 1.0 branch and the 1.0.x
releases until we are ready to cast a 2.0 branch and at that point 1.0
would be discontinued. Also at that point the 1.0 updaters are going to
automatically shift to 2.0.
The point of all this is to make sure that branch management is as
simple and as reliable as possible. Does anyone see a problem with this?