Constituting a Life Cycle for the Releases
Constituting a Life Cycle for the Releases
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
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
Re: Constituting a Life Cycle for the Releases
Hi Christoph,
yes, why not?
Holger
yes, why not?
Holger
Re: Constituting a Life Cycle for the Releases
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:
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:
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
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: ?
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
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
Re: Constituting a Life Cycle for the Releases
Sounds reasonable.
Publish it on http://www.cmsimple-xh.org/?History_and_Changelog?
And put the necessary tasks on the roadmap.
regards
manu
Publish it on http://www.cmsimple-xh.org/?History_and_Changelog?
And put the necessary tasks on the roadmap.
regards
manu
Re: Constituting a Life Cycle for the Releases
Good idea!manu wrote:Publish it on http://www.cmsimple-xh.org/?History_and_Changelog?
In which roadmap? Should we make new ones for 1.1.7, 1.4.5 and 1.5.7 and put it there?manu wrote:And put the necessary tasks on the roadmap.
Anyway, let's wait a while what others think about the actual dates.
Christoph M. Becker – Plugins for CMSimple_XH
Re: Constituting a Life Cycle for the Releases
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:
Maybe it's better to do so for admin mode only:
Christoph
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">
Code: Select all
<?php if ($adm):?><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"><?php endif;?>
Christoph M. Becker – Plugins for CMSimple_XH
Re: Constituting a Life Cycle for the Releases
Something to consider with regard to extensions: http://semver.org/.
Christoph M. Becker – Plugins for CMSimple_XH
Re: Constituting a Life Cycle for the Releases
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:
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
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
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
Re: Constituting a Life Cycle for the Releases
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...
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...