[commits] [Wiki] changed: Draft Release Cycle

[Chuck Hagenbuch]

chuck  Mon, 31 Jan 2011 00:01:37 -0500

Modified page: http://wiki.horde.org/Draft+Release+Cycle
New Revision:  1.1
Change log:  try to bring together, if not summarize, feedback from the list

@@ -2,12 +2,76 @@

  Draft of the Horde release cycle policy, put together from mailing  
list discussion in January/February 2011.

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

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

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

  ++ How long will old versions be supported?

-++ How many branches will be maintained at the same time?
+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.
+
+With the scheme suggested above we would have four active branches  
(development, active, stable, security) which might be too much. Three  
would sound better.
+
+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: 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.