[commits] [Wiki] changed: Doc/Dev/ReleaseCycle
Jan Schneider
jan at horde.org
Tue Jun 28 13:23:07 UTC 2011
jan Tue, 28 Jun 2011 13:23:07 +0000
Modified page: http://wiki.horde.org/Doc/Dev/ReleaseCycle
New Revision: 2.0
Change log: Update to the latest decided resp. evolved rules
@@ -1,61 +1,16 @@
++ Horde Release Cycle
-----
-+ Draft Horde Release Cycle
+This is an explanation of the Horde release model and the project's
release rules.
-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.
+* We will stick to [http://semver.org/ semantic versioning], this means:
+ * APIs* keep backward compatible within the same major versions. If
we have to break backward compatibility, Horde 4 becomes Horde 5 etc.
+ * Adding features or extending APIs will bump the minor version,
Horde 4.0 becomes Horde 4.1 etc.
+* New versions will be released every half a year. Whether these are
going to be major or minor version releases (or even just bug fix
releases) depends on whether the changes since the last release broke
BC or not.
+ * Intermediate releases can be be done for security fixes or bug fixes.
+* We will have sychronized releases of all application and framework
components. If it's going to be a minor version release, only the
modules that actually had any changes will be released. For major
versions, all modules will be relased.
+* Breaking backward compatibility will be documented, so that custom
applications can be updated easily. See ((Doc/Dev/ConversionH4)) for
an example.
+* The most recent two major versions will be maintained with security
fixes, i.e. for at least 12 months.
-++ When to break backward compatibility?
+*APIs in this context mean PHP APIs of framework components, external
PHP APIs of applications, and external Horde RPC APIs.
-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. ;-)
+See also ((Doc/Dev/Branches)) for an explanation of the branches used
to prepare releases.
More information about the commits
mailing list