[dev] Horde release cycle
wrobel at horde.org
Tue Jan 25 14:42:10 UTC 2011
As some of you may have noticed there is finally a fixed release date
for the next Horde version. In order for Horde4 to make it for April a
few features that were envisioned for that release had to be postponed.
Most of the developers currently feel that we need to adapt our
release cycle as Horde4 took significantly longer than initially
planned. So far we did follow a "it's done when it's done" scheme.
There is a strong tendency to switch this to time based releases. The
hope is that this would suit the different needs of the Horde project
a lot better and avoid some of the problems we see with our current
There are several critical questions that will determine the actual
1) When to break backward compatibility?
2) How often should new application versions be released?
3) How often should framework packages see new releases?
4) How long will old versions be supported?
5) How many branches will be maintained at the same time?
This list might not be complete and is just my attempt at kick
starting the discussion.
1) Breaking backward compatibility is a key issue. It determines how
fast the developers may move forward. This in turn also plays a role
in how fast new features can be delivered to end users. But backward
compatibility also has its part in determining how long a custom Horde
application any of you out there wrote will be provided with a
So far we have a history of keeping backward compatibility for a
very, very long time. But as far as we know most people will upgrade
the whole Horde system with every release anyway. So there is no need
to be able to run the most recent kronolith release with Horde 3.0.0.
Everyone probably uses 3.3.11 anyhow.
A good compromise might be to break backward compatibility every year.
2) Applications could be released in a synchronized manner every
half year. That would keep us in tune with some of the major Linux
distributions out there and might help packagers to deal with the
Horde applications. Security releases are a different matter of course.
3) Does a similar release scheme make sense for framework packages?
Maybe not as there are many of these and not all of them will see
changes during six months. In addition these are intended to be
distributed as small PHP component libraries with Horde4. So it could
make sense to publish bug fixes once these become available. But I
admit I'd prefer regular releases for these components as well.
4) I would like us to support the active version (which also gets
new features), the last stable version (which gets no new features but
the bug fixes) and the version before that (which only gets security
fixes). If that is the case and assuming we'd keep that scheme when
breaking backward compatibility every year then each version would see
support for three full years. In case that would not be enough one
might consider doing something like the long term support scheme
Ubuntu is doing.
5) With the scheme suggested above we would have four active
branches (development, active, stable, security) which might be too
much. Three would sound better.
In addition to the points above it might also be important what we can
actually do with PEAR. Horde4 will be fully PEAR based and hopefully
we can rely on the dependency management that comes with PEAR to
prevent users from accidentally pulling packages from mismatched
And last but not least the versioning is important too. Would we do
Horde5, Horde6, Horde7...? Or Horde 2011, Horde 2012, Horde 2013? I'm
somewhat in favor of the latter.
As mentioned these are just a few thoughts that come to my mind when
considering the release scheme. I'm certain I forgot a bunch of
important factors but hope we'll touch these in the discussion that
The Horde Project
e: wrobel at horde.org
t: +49 700 6245 0000
pgp: 9703 43BE
More information about the dev