6.0.0-beta1
7/3/25
Last Modified 6/28/11 by Jan Schneider

Draft Horde Release Cycle

Draft of the Horde release cycle policy, put together from mailing list discussion in January/February 2011. This is not intended to summarize all viewpoints, but to synthesize the discussion into a proposal.

When to break backward compatibility?

Backwards compatibility can be broken in each major version. We aim to release a new major version every 12-18 months.

  1. The existing API (method signatures and return values) will not change as long as the major version number is the same
  2. If new methods or classes (significant functionality) are added then a minor number is incremented
  3. When 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 18 months
  4. When we decide to break backward compatibility we document what has changed and make recommendations on how to update code to support the new version

How often should new application versions be released?

There will be new application feature releases every 6 months; every 12-18 months the release will be a new major version, otherwise they will be minor version releases. In addition, security releases will be made as soon as possible when issues are identified, and bugfix releases may be made in between feature releases.

How often should framework packages see new releases?

The framework packages will be versioned under the same rules as applications (breaking BC takes a major version release for a stable package, for example), but will only see synchronized releases as part of the Horde Core. Individual packages will be released as interesting features or useful bugfixes are available.

How long will old versions be supported?

We will support the current and previous major versions.

Additional context

Gonçalo Queirós

In my company we've been developing with Horde 4 for like one and half year. We have our own branch, where we change some Horde apps and Core, and some apps developed in-house, and we merge Horde code from time to time.

The gap between merges is usually one week (the train moves fast :-), but when we need to prepare a new release (yes we already have it in production), we stop merging with Horde since its development code, and we need some time to make tests etc...

Having 6 month releases would give us developers, the confidence that at least twice a year the code is in a stable state, and ready for production.

We didn't decide yet how we are going to work after H4 is released, but it also depends on how Horde plans releases, but i think we will have a stable branch that will only receive Horde bug-fixes and security updates plus in-house development, and a second branch, that would have all the previous branch code, plus weekly merges with Horde.
The second branch only exists so we can run some tests on it to find if anything is broken, and to allow us a fastest integration when new stable releases are done by Horde. But then again, this is in no way decided. We might also don't merge for the entire 6 months, and then take some days to make it.

As developers working with latest code, we also have some trouble finding information on what's going on and what's planned. Ok every app has it own roadmap, but that's it.
Im sure Horde developers have meetings somehow, where you decide what and how you will do things. It would be great to share with the community that thoughts , so we can understand a bit better where we are going to.

Ralf Lang

As a mostly external developer, I want to add my thoughts on BC breaking. I strongly advocate BC breaks when needed (the type of thing I expect from H4.x
-> H5 after maybe a year or two) and complete redesigns like H3->H4 only when you feel the old patterns really won't work any more.

The last 1-2 years asked difficult decisions for me, what's the way to go.

I had some non-public applications done and now I picked up eleusis in official horde repos.

For most of the time, H4 (git) was no viable option. Moving too fast, no guarantees, no release in sight, virtually no documentation or people to ask. On the other hand, the H3 way to do things asked a php4-ish approach and sometimes libraries/api's which the Horde Core developers themselves tried to replace already. I tricked myself around, using the latest H3 sometimes with components pulled from cvs-head and /incubator/.

I'm not complaining. The result of H4 development has been a big leap forward, both API wise and in applications. Also dropping PHP4 has helped a lot. On the other hand, I'd be glad to see more gradual changes even when breaking BC.

I don't think customers would want to pay a migration of any custom app from H3 to H4 while keeping H3 as a platform is definately a dead end.

Turning that to open source community development: I think most of the improvement patches geared to H3 versions which still await review would need more than just cosmetic changes to work in H4. Developing for the trash can doesn't attract casual committers. Yes, that's a bit harsh and shouldn't be taken too seriously. Just my thoughts.

I'm happy to see H4 coming and I'm waiting to package it for openSUSE 12. ;-)