[commits] [Wiki] created: Doc/Dev/ReleaseCycle

[Jan Schneider]

jan  Tue, 28 Jun 2011 13:07:02 +0000

Created page: http://wiki.horde.org/Doc/Dev/ReleaseCycle


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

# The existing API (method signatures and return values) will not  
change as long as the major version number is the same
# If new methods or classes (significant functionality) are added then  
a minor number is incremented
# 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
# 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. ;-)