Constituting a Life Cycle for the Releases

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Constituting a Life Cycle for the Releases

Post by cmb » Tue Dec 04, 2012 5:23 pm

Hello Community,

we should consider to constitute a life cycle for CMSimple_XH releases. As it's CMSimple it's probably enough to announce for each major and minor release how long this will be supported with security patches and fixes for major bugs, i.e. scheduling the end of life when the new version is released.

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Constituting a Life Cycle for the Releases

Post by Holger » Tue Dec 04, 2012 11:04 pm

Hi Christoph,

yes, why not?

Holger

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Constituting a Life Cycle for the Releases

Post by cmb » Fri Jan 11, 2013 12:44 am

Hello Community,

we have agreed upon that we should consitute a life cycle/end of life (EOL) for the releases. Now we should actually do it. ;)

A short summary of the relevant release dates:
  • XH 1.1: 2010-01-15
  • XH 1.2: 2010-10-15
  • XH 1.4: 2011-01-20
  • XH 1.5: 2011-12-19
  • XH 1.6: ?
Currently the latest releases of 1.1.x, 1.4.x and 1.5.x are available on SourceForge. It seems to me that the upgrade from 1.4.x to 1.5.x isn't too hard (recently managed it in less than an hour), so I suggest to schedule the end of life for the 1.4 series for 2013-06-30, which will still leave quite some time to upgrade.

Constituting the EOL for the 1.1 series seems to be harder. This is the last series delivered as single-byte encoded version (aka. ANSI encoded). The switch to UTF-8 seems to carry along quite some problems (e.g. changing deep links). Unfortunately there are no sufficient tools available to alleviate the switch to UTF-8, so even if this series is nearly 3 years old, I suggest to keep it at least for the running year; perhaps it's even appropriate to schedule the EOL not before 2014-12-31.

Regarding XH 1.5: this was released more than a year ago, and XH 1.6 isn't even there yet. As XH 1.6 seems to bring quite some changes, I suggest scheduling the EOL for 1.5 for 2014-06-30.

Summarizing my suggestions for the EOL dates:
  • 1.1.x: 2013-12-31 (assuming we'll manage to offer some tools to alleviate the upgrade till 2013-06-30)
  • 1.4.x: 2013-06-30
  • 1.5.x: 2014-06-30
This would result in about 2 1/2 years support for the 1.4 and 1.5 series and even nearly 4 years for the 1.1 series. I consider this some reasonable compromise regarding the convenience of the users vs. the extra time for the developers. N.B.: After the release of a new minor version, I consider only fixes for severe bugs and for major security issues to be made for older minor version, that still didn't reach their EOL.

It seems nearly impossible to me to schedule the EOL for CMSimple 1.x. As there are no tangible plans for the development after XH 1.6 (which is currently in progress), it's at least hard to schedule an EOL. As minimum we should consider 2015-12-31.

Scheduling 3 years ahead might seem to be somewhat dashing, particularly as some regard CMSimple_XH a bauble. Please consider, that CMSimple_XH is a community project, so probably possible alterations of the personnel may have little impact. :)

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

manu
Posts: 1086
Joined: Wed Jun 04, 2008 12:05 pm
Location: St. Gallen - Schweiz
Contact:

Re: Constituting a Life Cycle for the Releases

Post by manu » Sat Jan 12, 2013 4:44 pm

Sounds reasonable.
Publish it on http://www.cmsimple-xh.org/?History_and_Changelog?
And put the necessary tasks on the roadmap.
regards
manu

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Constituting a Life Cycle for the Releases

Post by cmb » Sun Jan 13, 2013 12:09 pm

Good idea!
manu wrote:And put the necessary tasks on the roadmap.
In which roadmap? Should we make new ones for 1.1.7, 1.4.5 and 1.5.7 and put it there?

Anyway, let's wait a while what others think about the actual dates.
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Constituting a Life Cycle for the Releases

Post by cmb » Sun Jan 27, 2013 12:37 pm

Hello Community,

I've added these dates to the History&Changelog, and a hint in the roadmaps to not forget them.

BTW: what shall we do with 1.1.x and 1.4.x? FCKeditor isn't fully functionable in IE 9 (the dialogs don't work AFAIK) and probably IE 10. I suggest that we mark this issue as "wontfix" and document that users of those versions should upgrade or use another browser. Another workaround is to force IE to compatibility mode by adding the following to the template:

Code: Select all

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"> 
Maybe it's better to do so for admin mode only:

Code: Select all

<?php if ($adm):?><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"><?php endif;?>
Christoph
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Constituting a Life Cycle for the Releases

Post by cmb » Wed Nov 20, 2013 11:45 pm

Something to consider with regard to extensions: http://semver.org/.
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Constituting a Life Cycle for the Releases

Post by cmb » Sat Jan 18, 2014 6:54 pm

Hello Community,

I'm bringing up this issue again, because I feel that it was an important step to schedule the life time of the releases in advance, but as time has shown it is as well important to more clearly define a full release process. The problem with the way we handle it currently is that it is never quite clear when to close the roadmap and to publish a new version; another problem is that we do not clearly enough distinguish bug fixes vs. new features. This often requires discussions on how to proceed which better should be avoided in favor of actually being productive.

I had a look at how other OS projects handle their release process. PHP as well as Wordpress schedule new versions in advance, whereby PHP has a new version every year, and Wordpress every 3-4 months. However, especially PHP doesn't schedule in advance yet when a major version will be released, so big changes which don't fit into a minor release are postponed over and over; there has not been a major release for nearly 10 years.

Joomla's release process handles this issue in a very interesting way: every 6 months a new version is released, of which every fourth is a major release. The last minor release before a major version is tagged as LTS (long term support; the others being STS = short term support), and is supported for 27 months (2 years until the next major release + 3 months cushion). Upgrading to a new major release might require some manual effort (i.e. a migration); updating to a minor or maintainace release should be semi-automatic. Maintainance releases are published as needed, where only the latest LST and STS releases are being maintained.

This release process has several advantages:
  • it is determined in advance when a new minor/major version will be released
  • the maintainance releases are mostly bug-fixes only, so there's no need for explicit voting, and the fixes can quickly be released
  • it is determined in advance when a new feature will be released (if at all); improvements are made available rather short term; major changes don't have to wait too long
  • the decision which feature requests to include has to happen only twice per year
  • users that are eagerly looking for new features are served rather timely
  • users prefering stability, don't have to upgrade too often
All in all I think this release process would fit nicely to CMSimple_XH.

Joomla specifies the detailed process for each minor and major version. This also seems not unreasonable, but we most likely would have to adapt it for our special needs (mainly the much smaller community).

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Constituting a Life Cycle for the Releases

Post by cmb » Sat Jan 25, 2014 12:17 am

bump
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Constituting a Life Cycle for the Releases

Post by Holger » Tue Jan 28, 2014 12:22 pm

Hi Christoph,

last days I've read the above mentioned articles and had my thoughts about it.

I agree with you that the way the Joomla dev's handle this would fit nicely for XH and that there are several advantages.
Maybe we should think about the 27 months for the LTS.
Releasing a new Version every 6 months seems to be fine on a first look, but then we should consider not to handle too strict what to put into maintainance releases. Maybe one or another "most wanted" - feature could be part of such a release beside bugfixes only.

All in all your propose gets my vote.

About the detailed process: of course we're a much smaller community and the project is much smaller too. But we should at least agree on some basic things...

Post Reply