[dev] Horde release cycle

Gunnar Wrobel wrobel at horde.org
Tue Jan 25 14:42:10 UTC 2011


Hi everyone!

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  
release scheme.

There are several critical questions that will determine the actual  
release cycle:

  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  
supported base.

     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  
branches.

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  
hopefully evolves.

Feedback welcome!

Gunnar

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de




More information about the dev mailing list