[Swfdec] Releases

[Benjamin Otte]

Hey,

We've just discussed this on IRC, but a wider circulation shouldn't
hurt: This mail is how we plan to do and number releases in the
future, now that Gnome has included swfdec-gnome.

The facts:
1. swfdec-gnome as part of a Gnome release needs to have a stable
release every 6 months, with bugfix/translation update releases during
at least the next 6 months. It should depend on a stable swfdec
package during that time.
2. Distributions want to ship swfdec (posibly s default install) and
they would like to ship an API stable library that is bugfixed.
3. Swfdec curently gets a release every 4-8 weeks (1-2 months) -
usually every 5-6 weeks.
4. Every one of those releases (with 1 exception during 0.4) changed
API of libswfdec due to having to do things differently after learning
stuff about Flash.
5. Those releases notably improve its capabilities, so it's nice if we
can make people upgrade to them.
6. None of the releases so far was really bad, even though they were
all unstable.

We ended up with a solution to this problem, which is very similar to
what Gnome currently does. Unless someone finds any poblems with it,
we're going to implement it like this. So here it goes:
We are going to release a new version with an even-numbered minor
version every 6 months to go with the Gnome release - 0.6 for Gnome
2.22, 0.8 for Gnome 2.24, 0.10 for Gnome 2.26 and so on. After such a
release, we'll immediately continue with an unstable version with an
odd-numbered minor version where we continue hacking, changing API and
releasing just like we do now. We'll also cherry-pick critical fixes
(and tests ;)) for the stable branch and do occasional releases of it,
so distros have a sane version to distribute.
Note that this will result in Swfdec releases being
parallel-installable. So you can install a stable branch to get a
stable Mozilla plugin but hack away using the unstable branch. Or
whatever else fits you.

I'd suggest that distributions should track the unstable branch in
their development versions (Debian sid, Debian sid, Gentoo etc) so the
people that want the newest features have a and ship a stable branch
when they do a release. For distributions tracking Gnome's 6-months
release this should come pretty natural with this, not sure about
other distros. If you're a packager and have problems with or
questions with this scheme, get n touch. This is not set in stone.

I'm also going to adopt Cairo's versioning scheme of using even minor
numbers for releases and odd minors for development versions. A
description of how this works can be seen at [1].

So, what does that mean in numbers? Something like this:
0.5.6 - End of January/Start of Feruary
I'm not sure if we'll have features that want out by then, so it could
be we skip this
0.6.0 - End of February
This date is pretty set in stone, because we want this for Gnome 2.22.
0.6.2 - End of March/Start of April?
I guess when lots of new people get exposed to Swfdec, they'll
probably find far too many new crashers, so we'll need a new release
with fixes pretty soon.
0.7.2 - probably April
Depending on the work needed to solidify 0.6 and on the rest of our
lives, we'll add new features to Swfdec and cut a release when we
think were happy.
...

Cheers,
Benjamin

[1]: http://mail.gnome.org/archives/desktop-devel-list/2007-December/msg00103.html