[dev] Horde release cycle

Tue Jan 25 18:50:39 UTC 2011

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

Completely agree here. 

> 
>    A good compromise might be to break backward compatibility every year.

I'm not sure I'd phrase it quite this way.  Doing development eventually means breaking backward compatibility as systems and features evolve.  That being said, there's no automatic requirement to break backward compatibility when developing so I don't think it makes sense to say "we are going to break backward compatibility every year."  What is more important to me is the promise we make to consumers of our software.   To me the promise should be something like this:

1) The existing API (method signatures and return values) will not change as long as the major number is the same
2) If new methods or classes (significant functionality) are added then a minor number is incremented
3) When and if we decide to break backward compatibility in a given library or application we will commit to supporting the latest release of the old major version with security updates for a period of time (example: 2 years)
4) When and if we decide to break backward compatibility we document what has changed and, ideally, make recommendations on how to update code to support the new version.

It's bad for everyone if we are requiring frequent backward-incompatible changes.  I know that many of us core developers feel a lot of strain over the last five years as *no* backward incompatible change has been made.  Clearly, with Horde 4, we need to move on.

All of the above applies to the public-facing Framework APIs as well as the external-facing Horde application APIs, such as SOAP, XML-RPC or any of the DAV implementations.

With that said, my vote would be that we commit to avoiding any backward compatible change for at least 18 months from the first release of a new major version.  Forward-incompatible changes, such as adding new methods or classes, would be exempt from this.

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

This works for me as well.  Again whatever our promise is as far as security updates needs to be documented publicly on our website somewhere so distributions and packagers know what to expect.

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

I think there's a difference in Framework packages versus Horde packages.  Personally I feel no need to release library packages on any regular basis.  For example, the Horde Cache SQL driver pretty much does what it needs to and, bugs aside, doesn't need to do much more.  My feeling is that it should be updated and released only as needed.

Now, when we are talking about releasing Horde and associated applications as a package, then I do agree that we need a regular release schedule.  My preference would be to make a new minor version release every 6 months and a new major version release approximately every 18 months.  Whatever changes we have in Git when release time comes get tested, polished and documented then released as close to the due date as possible.

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

#4 and #5: This seems like too much work to me, but I think it is more important to get feedback from the community here.  Personally, I'm fine with only two maintained branches:
1) The latest current major version release (new features, bugfixes and security)
2) The last release of the previous major version (security and critical bugfixes only).

We will always have a development branch as well of course but no guarantees are made at all.

> 
> 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.
> 
Agreed.  This versioning and dependency should also be available in any other packaging mechanism we distribute, such as RPM or DPKG as appropriate.

> 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.
> 
I dislike year-based version numbers.  I'm a fan of Semantic Versioning, which is reflected in my comments above: http://semver.org/

> 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.
> 
Thanks for getting the discussion started!

/BAK/
-- 
Ben Klang
Core Developer
The Horde Project
bklang at horde.org
http://www.horde.org