[mono-packagers] release frequency

[Jo Shields]

On Mon, 2008-12-08 at 17:37 -0700, Andrew Jorgensen wrote:
> A discussion has started on our internal mailing list regarding mono's release frequency.  The current plan is 4 releases per year.  We want input from packagers.  Please reply with your thoughts about this and I will do my best to champion them.  How does our release schedule impact you?  How does it impact your distro?  How many releases per year would work best?  Any other thoughts?

It's probably easiest for me to point back to a message I sent last
month for this:
http://lists.ximian.com/pipermail/mono-packagers-list/2008-November/000040.html

Paul can correct me on this, but I believe Ubuntu is not the only
distribution on a 6-month schedule - Fedora's last four releases (and
their next one) seem to be released in late May and late November. For
Ubuntu, releases are in late April and October.

OpenSUSE doesn't seem to have anything quite so concrete - the gaps from
10.0 onwards were 7 months, 7 months, 8 months, 8 months, and a
projected 6 months. 

I don't know about Fedora, but for Ubuntu, those dates are pretty firm.
Importantly, the QA cycle is a little longer in Ubuntu, meaning package
versions are frozen relatively far in advance (a major update to a core
framework like Mono would be very hard to argue past T-2, and impossible
past T-1).

Given the need for thorough testing, and the frequent major changes
between upstream versions, even if the dates matched up perfectly, I
doubt we'd ever be able to include a "current" Mono in a stable release
(i.e. by the time we have a version packaged, tested, and integrated
into the distro, and the distro released - a new version will be out and
people moaning that we're obsolete). Certainly not with 4 major releases
a year.

The question from where I'm sat, then, becomes "who benefits from your
3-month proposal"? If no distribution is releasing that frequently, then
where is the advantage in integrating a Mono release into a development
distro (cooker, rawhide, factory, whatever) when you know it will never
be part of that release?

Here's my counter-proposal: In keeping with the majority of
distributions running on a 6-month (or approximately 6-month) schedule,
how about releasing major Mono versions on a 6-month basis as well? A
major Mono version every 6 months which warrants the packaging work
involved - with as many intermediary bugfix-only releases in between as
are deemed necessary. Packagers then know which "major" release they
need to work with, work towards, and test - and at worst they only
differ by minor point releases (where some or all of the point release
fixes may end up being used anyway).

Now, time for some stats. Here's a table of major distro releases, the
Mono versions included, the release date, and the age of the Mono
release on that date. It should help to give an indication of which
distros need how much time to work, and point towards a good date for
major Mono releases:

Fedora 7  | 2007/05/31 | 1.2.3   | 4 months
Fedora 8  | 2007/11/08 | 1.2.4   | 4 months
Fedora 9  | 2008/05/13 | 1.9.1   | 1 month
Fedora 10 | 2008/11/25 | 2.0.1   | 1 month
SUSE 10.3 | 2007/10/04 | 1.2.5   | 3 months
SUSE 11.0 | 2008/06/19 | 1.9.1   | 2 months
Ubun 7.04 | 2007/04/19 | 1.2.3.1 | 2 months
Ubun 7.10 | 2007/10/18 | 1.2.4   | 3 months
Ubun 8.04 | 2008/04/24 | 1.2.6   | 5 months
Ubun 8.10 | 2008/10/30 | 1.9.1   | 6 months

Clearly the turnaround is longer for Ubuntu than the others. There are a
few reasons for this, which can generally be summed up with "more
complex packaging, more QA, more architectures" - our cooperation with
Debian is invaluable, but also makes us weak to the sometimes (always)
protracted delays between Debian releases. I've declined to list Debian
in the table since, despite being one of the oldest Mono-containing
distributions, it's essentially impossible to predict or work towards
Debian release dates.

Some of those delays are of our own making: because we split pretty much
everything into its own package, we save a lot on disk space, but it
takes more time to test.

Some of them are yours:
* Arbitrarily changing whether 'foo' is a 1.0 or 2.0 corlib app is a
major problem, especially when mixed & matched, as it breaks automated
dependency tracking
* Major releases frequently require significant patching, such as the 25
patches to 1.9.1 shown on
http://svn.debian.org/wsvn/pkg-mono/mono/branches/1.9.1-X/debian/patches/?rev=0&sc=0 - yes, some are Debianisms, but three are security patches and ten are required SVN backports to fix real problems. This number of patches is not an anomaly.

So. Back to the start again. What would I like to see from upstream
release schedules?
* 2 major releases, and as many bugfix-only releases as seem necessary,
per year
* Feature freeze ASAP - so packaging work can begin as soon as possible
and potential changes or issues resolved early
* Don't make a major Mono release days before a distro releases, unless
they have a phenomenal turnaround time - it makes the distro look bad,
and has users breaking their systems with "make install" from pretty
much day of release

--Jo Shields