[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