[commits] [Wiki] changed: Draft Release Cycle

Chuck Hagenbuch chuck at horde.org
Mon Jan 31 05:30:57 UTC 2011


chuck  Mon, 31 Jan 2011 00:30:57 -0500

Modified page: http://wiki.horde.org/Draft+Release+Cycle
New Revision:  1.2
Change log:  synthesize into a proposal

@@ -1,71 +1,34 @@
  + Draft Horde Release Cycle

-Draft of the Horde release cycle policy, put together from mailing  
list discussion in January/February 2011.
+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?

-Gunnar: 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.
+Backwards compatibility can be broken in each major version. We aim  
to release a new major version every 12-18 months.

-    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.
-
-Ben: 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.
+# 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?

-Gunnar: 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.
-
-Ben:  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.
-
-Jan:  In addition we should release bug fixes when we find the time,  
and security fixes as necessary, both in between this regular release  
schedule.
-
-Chuck:  I feel like bugfixes need to be released more than every 6 months.
-
-Michael R: Agreed, for the most part. Minor/Major feature releases  
should be done at the six month release date. With such a short  
release cycle, however, I don't see the problem with waiting until the  
next release date to push minor, non-security bug fixes. I'm not  
saying we *never* release non-security releases between cycles.  
Obviously, something that could be considered a major issue could be  
released sooner.
-
-Jan: So you're even going one step further by not requiring a minor  
version release after 6 months if we didn't add any new features. I  
can live with that too.
+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?

-Gunnar: 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.
+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?

-Gunnar: 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.
+We will support the current and previous major versions.

-With the scheme suggested above we would have four active branches  
(development, active, stable, security) which might be too much. Three  
would sound better.
+++ Additional context

-Ben: 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).
-
-Jan: I'm not sure. Wouldn't we release new (minor) versions basically  
from master? I see it working this way: when we start to polish the  
next minor release, we branch off master, so that we can keep hacking  
there with not-to-be-release code while we prepare the release. If  
there is really some major developement going on that we don't feel  
should slip into the next release, such development should happen in a  
topic branch anyway. So master is basically what's going into the next  
release. If code in master broke BC, we release a new major version,  
if not, we release a minor version (see above).
-This way we keep 3 active branches, master for the next release, say  
Horde 5 or 4.2, a security branch e.g FRAMEWORK_4_0, and a bug fix  
branch, e.g. FRAMEWORK_4_1.
-Only for the (hopefully) very short time span of polishing the  
release, we have a 4th active branch. This is btw how we already  
worked in the past.
-
-Michael R: I agree with Jan. I like the way we have typically handled  
this and would like to continue in this way.
-
-Jan: The only solution I see is to add LTS releases to that equation.  
I like the more formal approach of Ubuntu better than the  
randomly-picked-stable-version of Kernel development, which is harder  
to follow.
-But I don't see us having the man power for that at the moment. Let's  
he how the release plan works that we're discussing here, and what the  
feedback is. I have no idea how often we are going to break BC in  
reality, how big those BC breaks are to pose a problem for 3rd-party  
developers, and if developers are going to ask for longer version  
support.
-
-Chuck: I agree with Jan that LTS is the way to go if we need it, but  
we should try breaking BC (and releasing major features) more often  
and see if we need it.
-
-++ Additional context
++++ Gonçalo Queirós

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



More information about the commits mailing list