Hi everyone. Below is an outline of a new proposed release cycle for Joomla. Please note that this is only a proposal at this point. This is based on Louis Landry's ideas that the Dev Coordinators and Production Work Group discussed at the NYC Dev Conference. If we adopt it, it would start after version 1.6 is shipping and stable.
We are excited about this idea and think it is a good direction for the project. However, we need to hear what the community thinks about it. So, please read it and let us know what you think! Thanks. Mark Dexter
*Proposal for New Joomla! Release Cycle*
*Background*
Version 1.5 was released on 22 January 2008. As of this writing in December 2009, version 1.6 is planned to release in Q1 or Q2 of 2010, more than two years after version 1.5. This document proposes a process to shorten the release cycle so that new Joomla! versions can be released more frequently, for example every six months.
*Objectives*
* *
The objectives of the proposed release cycle are:
1. Continue to offer a stable, reliable platform for our current and future user base. 2. Make new core features available to the community on a more timely basis. 3. Allow developers to write and contribute code to the project at any time in the release cycle. 4. Make it easier for community developers to contribute features to the project. 5. Make our release cycle more like other FOSS projects, such as Eclipse and Ubuntu.
*Executive Summary*
The new strategy is based on four key practices.
*Stable Trunk.* The main trunk of the SVN code repository will only be updated in one of two ways: (1) from patches containing tested bug fixes from the Bug Squad; (2) from merges from feature branches that have been completed and approved by the development team. In this way, the main trunk of the SVN will always contain a stable version that can be made ready for release in a short time (for example, 30 – 60 days).
"*Contract with Users". *Maintain a "contract" with users that says that new Joomla! releases and new features will not break existing, documented functionality. Because of this, users will be able to update their sites to new releases as they become available, just like they have been able to do with version 1.5 maintenance releases.
*Date-Based Releases. *Release based on calendar dates, for example, every 6 months. Features that are approved and ready in time for a release will be included. Features that are not ready will not be included (but could be included in the next release).
* *
*Open Development Environment. *Anyone who wants to will be able to create an account, create an SVN branch, and start coding. The development team will of course exercise final say on whether a feature gets included into the core product. It is hoped that developers familiar with other FOSS projects will find the process familiar and easy.
* *
*Example Scenario*
* *
For this example, we are releasing a maintenance release every 2 months and a feature release every 6 months. The dates and version numbers are for illustration only.
* *
Date
Activity
July 1
Version 1.8.0 released.
July 15
Group A completes feature in Branch A
August 5
Group B completes feature in Branch B
July 1 – September 1
Bug Squad commits patches to main SVN trunk
September 1
Version 1.8.1 released
September 20
Group C completes feature in Branch C
September 1 – November 1
Bug Squad commits patches to main SVN trunk
November 1
Version 1.8.2 released
November 2
Branches A, B, C merged to trunk
November 2 – December 31
Bug Squad commits patches to main SVN trunk
November 2 – December 31
Testing, bug fixes on new features
November 15
Group D completes feature in Branch D (this will wait for the next release after 1.9.0)
January 1
Version 1.9.0 released.
* *
In this scenario, we can have any number of individuals or groups working on new features for Joomla. Each person or group works in a branch of the SVN and keeps their branch up to date with the main SVN trunk as bugs are fixed in trunk.
When a feature branch is complete and stable, the code can be reviewed, tested, and approved for release in the next feature release. Any number of these branches can be worked on at one time. Obviously, there is the potential for conflicts and we will need to coordinate efforts when people want to work on overlapping functionality. If two groups are both working in the same area of the code, for example, it might make sense for them to join forces and work in a common branch. In other cases, two separate approaches to the same problem might be tried by different groups and the best one might be adopted into the package.
After the last maintenance release, the features that are approved and stable in the branches as of this time are merged into the trunk. At this point, we have frozen the features and only these new features will be included in the release. Others can continue to develop new features in branches, but they will be for the next release.
The last period of time is to get the new features ready for release. In this example, we have from November 2 until December 31 to test the new features, fix bugs, release a beta or release candidate version, and update our documentation.
*Other Observations*
- The period of six months was picked for this proposal to illustrate the point. The idea behind this proposal will also work with a longer cycle, such as 12 months. - It might make sense to designate some releases for long-term security upgrades. For example, say that 1.6 releases March 31, 2010 and 1.7 releases December 31, 2010. We could continue to provide security releases for 1.6 for 1 – 2 years. So users would have the choice to upgrade to 1.7, 1.8, 1.9 or to continue on 1.6 and eventually upgrade to 2.0. - The scenario outlined above assumes we will merge feature branches "just in time" for the next release. An alternative approach would be for the project to maintain an "official" branch of approved, merged features and merge new feature branches into this branch as soon as they are approved. That way, there would be more time to test these features and perhaps functional tests could be written for the new features as they are added. - The proposed cycle has a big advantage with respect to GSoC and GHOP. Both of these programs offer the opportunity to get code written. However, we don't have control over the timing of these contributions. For example, this past summer was "too soon" for 1.6, since there wasn't a stable version ready for most of the summer. But in another way it was "too late" for 1.6, since we already had a quasi-freeze on new features (because people were understandably worried about delaying it's release). Having a release cycle where we can always accept code contributions and where we have a way to get them into core in a reasonable timeframe could make it possible for us to make better use of these contributions. - Version end-of-life would occur 6 months after a new version is released. For example, assume 1.8 is release on 1 July 2010. If 1.9 comes out on 1 January 2011, then 1.8 would only be patched with security fixes after this date up until 1 July 2011.
That's a great proposal. It will speed the release cycle up while keeping Joomla! open for improvements over it's life span. Quite differente (and better) than what we have with the 1.5 family, where new features are almost completely prohibited (with just a few exceptions made).
This new release cycle will most certainly give back to Joomla! it's edge over other CMS's.
----- Original Message ----- From: Mark Dexter To: Joomla! General Development Sent: Thursday, December 17, 2009 11:34 PM Subject: Possible New Release Cycle for Joomla!
Hi everyone. Below is an outline of a new proposed release cycle for Joomla. Please note that this is only a proposal at this point. This is based on Louis Landry's ideas that the Dev Coordinators and Production Work Group discussed at the NYC Dev Conference. If we adopt it, it would start after version 1.6 is shipping and stable.
We are excited about this idea and think it is a good direction for the project. However, we need to hear what the community thinks about it. So, please read it and let us know what you think! Thanks. Mark Dexter
Proposal for New Joomla! Release Cycle
Background
Version 1.5 was released on 22 January 2008. As of this writing in December 2009, version 1.6 is planned to release in Q1 or Q2 of 2010, more than two years after version 1.5. This document proposes a process to shorten the release cycle so that new Joomla! versions can be released more frequently, for example every six months.
Objectives
The objectives of the proposed release cycle are:
1.. Continue to offer a stable, reliable platform for our current and future user base. 2.. Make new core features available to the community on a more timely basis. 3.. Allow developers to write and contribute code to the project at any time in the release cycle. 4.. Make it easier for community developers to contribute features to the project. 5.. Make our release cycle more like other FOSS projects, such as Eclipse and Ubuntu. Executive Summary
The new strategy is based on four key practices.
Stable Trunk. The main trunk of the SVN code repository will only be updated in one of two ways: (1) from patches containing tested bug fixes from the Bug Squad; (2) from merges from feature branches that have been completed and approved by the development team. In this way, the main trunk of the SVN will always contain a stable version that can be made ready for release in a short time (for example, 30 – 60 days).
"Contract with Users". Maintain a "contract" with users that says that new Joomla! releases and new features will not break existing, documented functionality. Because of this, users will be able to update their sites to new releases as they become available, just like they have been able to do with version 1.5 maintenance releases.
Date-Based Releases. Release based on calendar dates, for example, every 6 months. Features that are approved and ready in time for a release will be included. Features that are not ready will not be included (but could be included in the next release).
Open Development Environment. Anyone who wants to will be able to create an account, create an SVN branch, and start coding. The development team will of course exercise final say on whether a feature gets included into the core product. It is hoped that developers familiar with other FOSS projects will find the process familiar and easy.
Example Scenario
For this example, we are releasing a maintenance release every 2 months and a feature release every 6 months. The dates and version numbers are for illustration only.
Date Activity
July 1 Version 1.8.0 released.
July 15 Group A completes feature in Branch A
August 5 Group B completes feature in Branch B
July 1 – September 1 Bug Squad commits patches to main SVN trunk
September 1 Version 1.8.1 released
September 20 Group C completes feature in Branch C
September 1 – November 1 Bug Squad commits patches to main SVN trunk
November 1 Version 1.8.2 released
November 2 Branches A, B, C merged to trunk
November 2 – December 31 Bug Squad commits patches to main SVN trunk
November 2 – December 31 Testing, bug fixes on new features
November 15 Group D completes feature in Branch D (this will wait for the next release after 1.9.0)
January 1 Version 1.9.0 released.
In this scenario, we can have any number of individuals or groups working on new features for Joomla. Each person or group works in a branch of the SVN and keeps their branch up to date with the main SVN trunk as bugs are fixed in trunk.
When a feature branch is complete and stable, the code can be reviewed, tested, and approved for release in the next feature release. Any number of these branches can be worked on at one time. Obviously, there is the potential for conflicts and we will need to coordinate efforts when people want to work on overlapping functionality. If two groups are both working in the same area of the code, for example, it might make sense for them to join forces and work in a common branch. In other cases, two separate approaches to the same problem might be tried by different groups and the best one might be adopted into the package.
After the last maintenance release, the features that are approved and stable in the branches as of this time are merged into the trunk. At this point, we have frozen the features and only these new features will be included in the release. Others can continue to develop new features in branches, but they will be for the next release.
The last period of time is to get the new features ready for release. In this example, we have from November 2 until December 31 to test the new features, fix bugs, release a beta or release candidate version, and update our documentation.
Other Observations
a.. The period of six months was picked for this proposal to illustrate the point. The idea behind this proposal will also work with a longer cycle, such as 12 months. b.. It might make sense to designate some releases for long-term security upgrades. For example, say that 1.6 releases March 31, 2010 and 1.7 releases December 31, 2010. We could continue to provide security releases for 1.6 for 1 – 2 years. So users would have the choice to upgrade to 1.7, 1.8, 1.9 or to continue on 1.6 and eventually upgrade to 2.0. c.. The scenario outlined above assumes we will merge feature branches "just in time" for the next release. An alternative approach would be for the project to maintain an "official" branch of approved, merged features and merge new feature branches into this branch as soon as they are approved. That way, there would be more time to test these features and perhaps functional tests could be written for the new features as they are added. d.. The proposed cycle has a big advantage with respect to GSoC and GHOP. Both of these programs offer the opportunity to get code written. However, we don't have control over the timing of these contributions. For example, this past summer was "too soon" for 1.6, since there wasn't a stable version ready for most of the summer. But in another way it was "too late" for 1.6, since we already had a quasi-freeze on new features (because people were understandably worried about delaying it's release). Having a release cycle where we can always accept code contributions and where we have a way to get them into core in a reasonable timeframe could make it possible for us to make better use of these contributions. e.. Version end-of-life would occur 6 months after a new version is released. For example, assume 1.8 is release on 1 July 2010. If 1.9 comes out on 1 January 2011, then 1.8 would only be patched with security fixes after this date up until 1 July 2011.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group. To post to this group, send an email to joomla-dev-general@googlegroups.com. To unsubscribe from this group, send email to joomla-dev-general+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
The new release cycle seems to be a very obtainable goal.
Anything that can be done to encourage community involvement is a positive. We want to encourage our community, not throw roadblocks and detours in its way!
We need to do what we can to get our community more involved with the Joomla! project!
Go Joomla!,
Mark W. Bender AllTogetherAsAWhole.org Community Project Manager
On Dec 17, 9:39 pm, "Airton Torres" <airton.tor...@gmail.com> wrote:
> That's a great proposal. It will speed the release cycle up while keeping Joomla! open for improvements over it's life span. Quite differente (and better) than what we have with the 1.5 family, where new features are almost completely prohibited (with just a few exceptions made).
> This new release cycle will most certainly give back to Joomla! it's edge over other CMS's.
I totally agree with this new proposal. I'm also for an approved up-to- date branch (with a nighly build) where bugs are corrected and new approved features are merged.
I also like this proposal. There is only one thing I would change and it's the time between releases. I think 6 months are not enough.
1. From the Joomla! project point of view: Even if we start the Labs site and allow people to contribute easily, adding new features, testing and documenting them is not easy. So I'm afraid we will have to postpone the release date many times, or we will release an application with full of bugs.
2. From the user / developer point of view: Again, this time is too short. Developers have to update their extensions to work with the new release. This can be started just after a Beta release. When developers update their extensions (it can take month for a component), users can start updating their sites, which will also take some time. And when they are finally ready, the new release of Joomla is out and they can start the whole process again.
Ubuntu has a 6 months long release cycle, but first of all there is a much larger community behind Ubuntu than behind Joomla, secondly many times a stable release actually very unstable. So instead of releasing an unstable CMS each time, I would suggest to spend some more time on it, for example 9-12 months.
I'm not sure this topic is about the strategy itself or about any part of it. If the length of the release cycle is part of an other discussion, please ignore this post.
> Hi everyone. Below is an outline of a new proposed release cycle for Joomla. Please note that this is only a proposal at this point. This is based on Louis Landry's ideas that the Dev Coordinators and Production Work Group discussed at the NYC Dev Conference. If we adopt it, it would start after version 1.6 is shipping and stable.
> We are excited about this idea and think it is a good direction for the project. However, we need to hear what the community thinks about it. So, please read it and let us know what you think! Thanks. Mark Dexter
> Proposal for New Joomla! Release Cycle
> Background
> Version 1.5 was released on 22 January 2008. As of this writing in December 2009, version 1.6 is planned to release in Q1 or Q2 of 2010, more than two years after version 1.5. This document proposes a process to shorten the release cycle so that new Joomla! versions can be released more frequently, for example every six months.
> Objectives
> The objectives of the proposed release cycle are: > Continue to offer a stable, reliable platform for our current and future user base. > Make new core features available to the community on a more timely basis. > Allow developers to write and contribute code to the project at any time in the release cycle. > Make it easier for community developers to contribute features to the project. > Make our release cycle more like other FOSS projects, such as Eclipse and Ubuntu. > Executive Summary
> The new strategy is based on four key practices.
> Stable Trunk. The main trunk of the SVN code repository will only be updated in one of two ways: (1) from patches containing tested bug fixes from the Bug Squad; (2) from merges from feature branches that have been completed and approved by the development team. In this way, the main trunk of the SVN will always contain a stable version that can be made ready for release in a short time (for example, 30 – 60 days).
> "Contract with Users". Maintain a "contract" with users that says that new Joomla! releases and new features will not break existing, documented functionality. Because of this, users will be able to update their sites to new releases as they become available, just like they have been able to do with version 1.5 maintenance releases.
> Date-Based Releases. Release based on calendar dates, for example, every 6 months. Features that are approved and ready in time for a release will be included. Features that are not ready will not be included (but could be included in the next release).
> Open Development Environment. Anyone who wants to will be able to create an account, create an SVN branch, and start coding. The development team will of course exercise final say on whether a feature gets included into the core product. It is hoped that developers familiar with other FOSS projects will find the process familiar and easy.
> Example Scenario
> For this example, we are releasing a maintenance release every 2 months and a feature release every 6 months. The dates and version numbers are for illustration only.
> Date > Activity > July 1 > Version 1.8.0 released. > July 15 > Group A completes feature in Branch A > August 5 > Group B completes feature in Branch B > July 1 – September 1 > Bug Squad commits patches to main SVN trunk > September 1 > Version 1.8.1 released > September 20 > Group C completes feature in Branch C > September 1 – November 1 > Bug Squad commits patches to main SVN trunk > November 1 > Version 1.8.2 released > November 2 > Branches A, B, C merged to trunk > November 2 – December 31 > Bug Squad commits patches to main SVN trunk > November 2 – December 31 > Testing, bug fixes on new features > November 15 > Group D completes feature in Branch D (this will wait for the next release after 1.9.0) > January 1 > Version 1.9.0 released.
> In this scenario, we can have any number of individuals or groups working on new features for Joomla. Each person or group works in a branch of the SVN and keeps their branch up to date with the main SVN trunk as bugs are fixed in trunk.
> When a feature branch is complete and stable, the code can be reviewed, tested, and approved for release in the next feature release. Any number of these branches can be worked on at one time. Obviously, there is the potential for conflicts and we will need to coordinate efforts when people want to work on overlapping functionality. If two groups are both working in the same area of the code, for example, it might make sense for them to join forces and work in a common branch. In other cases, two separate approaches to the same problem might be tried by different groups and the best one might be adopted into the package.
> After the last maintenance release, the features that are approved and stable in the branches as of this time are merged into the trunk. At this point, we have frozen the features and only these new features will be included in the release. Others can continue to develop new features in branches, but they will be for the next release.
> The last period of time is to get the new features ready for release. In this example, we have from November 2 until December 31 to test the new features, fix bugs, release a beta or release candidate version, and update our documentation.
> Other Observations > The period of six months was picked for this proposal to illustrate the point. The idea behind this proposal will also work with a longer cycle, such as 12 months. > It might make sense to designate some releases for long-term security upgrades. For example, say that 1.6 releases March 31, 2010 and 1.7 releases December 31, 2010. We could continue to provide security releases for 1.6 for 1 – 2 years. So users would have the choice to upgrade to 1.7, 1.8, 1.9 or to continue on 1.6 and eventually upgrade to 2.0. > The scenario outlined above assumes we will merge feature branches "just in time" for the next release. An alternative approach would be for the project to maintain an "official" branch of approved, merged features and merge new feature branches into this branch as soon as they are approved. That way, there would be more time to test these features and perhaps functional tests could be written for the new features as they are added. > The proposed cycle has a big advantage with respect to GSoC and GHOP. Both of these programs offer the opportunity to get code written. However, we don't have control over the timing of these contributions. For example, this past summer was "too soon" for 1.6, since there wasn't a stable version ready for most of the summer. But in another way it was "too late" for 1.6, since we already had a quasi-freeze on new features (because people were understandably worried about delaying it's release). Having a release cycle where we can always accept code contributions and where we have a way to get them into core in a reasonable timeframe could make it possible for us to make better use of these contributions. > Version end-of-life would occur 6 months after a new version is released. For example, assume 1.8 is release on 1 July 2010. If 1.9 comes out on 1 January 2011, then 1.8 would only be patched with security fixes after this date up until 1 July 2011.
> --
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group. > To post to this group, send an email to joomla-dev-general@googlegroups.com. > To unsubscribe from this group, send email to joomla-dev-general+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
This is the perfect Mark. +1 for it . But Gergo's changes are making sense too ... JoomlaLab Website will be a good idea. So we can add this point into your new proposed release cycle.
> I also like this proposal. There is only one thing I would change and it's > the time between releases. I think 6 months are not enough.
> 1. From the Joomla! project point of view: Even if we start the Labs site > and allow people to contribute easily, adding new features, testing and > documenting them is not easy. So I'm afraid we will have to postpone the > release date many times, or we will release an application with full of > bugs.
> 2. From the user / developer point of view: Again, this time is too short. > Developers have to update their extensions to work with the new release. > This can be started just after a Beta release. When developers update their > extensions (it can take month for a component), users can start updating > their sites, which will also take some time. And when they are finally > ready, the new release of Joomla is out and they can start the whole process > again.
> Ubuntu has a 6 months long release cycle, but first of all there is a much > larger community behind Ubuntu than behind Joomla, secondly many times a > stable release actually very unstable. So instead of releasing an unstable > CMS each time, I would suggest to spend some more time on it, for example > 9-12 months.
> I'm not sure this topic is about the strategy itself or about any part of > it. If the length of the release cycle is part of an other discussion, > please ignore this post.
> --- > Gergo Erdosi
> On 18 Dec 2009, at 03:34, Mark Dexter wrote:
> Hi everyone. Below is an outline of a new proposed release cycle for > Joomla. Please note that this is only a proposal at this point. This is > based on Louis Landry's ideas that the Dev Coordinators and Production Work > Group discussed at the NYC Dev Conference. If we adopt it, it would start > after version 1.6 is shipping and stable.
> We are excited about this idea and think it is a good direction for the > project. However, we need to hear what the community thinks about it. So, > please read it and let us know what you think! Thanks. Mark Dexter
> *Proposal for New Joomla! Release Cycle*
> *Background*
> Version 1.5 was released on 22 January 2008. As of this writing in December > 2009, version 1.6 is planned to release in Q1 or Q2 of 2010, more than two > years after version 1.5. This document proposes a process to shorten the > release cycle so that new Joomla! versions can be released more frequently, > for example every six months.
> *Objectives* > * * > The objectives of the proposed release cycle are:
> 1. Continue to offer a stable, reliable platform for our current and > future user base. > 2. Make new core features available to the community on a more timely > basis. > 3. Allow developers to write and contribute code to the project at any > time in the release cycle. > 4. Make it easier for community developers to contribute features to > the project. > 5. Make our release cycle more like other FOSS projects, such as > Eclipse and Ubuntu.
> *Executive Summary*
> The new strategy is based on four key practices.
> *Stable Trunk.* The main trunk of the SVN code repository will only be > updated in one of two ways: (1) from patches containing tested bug fixes > from the Bug Squad; (2) from merges from feature branches that have been > completed and approved by the development team. In this way, the main trunk > of the SVN will always contain a stable version that can be made ready for > release in a short time (for example, 30 – 60 days).
> "*Contract with Users". *Maintain a "contract" with users that says that > new Joomla! releases and new features will not break existing, documented > functionality. Because of this, users will be able to update their sites to > new releases as they become available, just like they have been able to do > with version 1.5 maintenance releases.
> *Date-Based Releases. *Release based on calendar dates, for example, every > 6 months. Features that are approved and ready in time for a release will be > included. Features that are not ready will not be included (but could be > included in the next release). > * * > *Open Development Environment. *Anyone who wants to will be able to create > an account, create an SVN branch, and start coding. The development team > will of course exercise final say on whether a feature gets included into > the core product. It is hoped that developers familiar with other FOSS > projects will find the process familiar and easy. > * * > *Example Scenario* > * * > For this example, we are releasing a maintenance release every 2 months and > a feature release every 6 months. The dates and version numbers are for > illustration only. > * * > Date > Activity > July 1 > Version 1.8.0 released. > July 15 > Group A completes feature in Branch A > August 5 > Group B completes feature in Branch B > July 1 – September 1 > Bug Squad commits patches to main SVN trunk > September 1 > Version 1.8.1 released > September 20 > Group C completes feature in Branch C > September 1 – November 1 > Bug Squad commits patches to main SVN trunk > November 1 > Version 1.8.2 released > November 2 > Branches A, B, C merged to trunk > November 2 – December 31 > Bug Squad commits patches to main SVN trunk > November 2 – December 31 > Testing, bug fixes on new features > November 15 > Group D completes feature in Branch D (this will wait for the next release > after 1.9.0) > January 1 > Version 1.9.0 released. > * * > In this scenario, we can have any number of individuals or groups working > on new features for Joomla. Each person or group works in a branch of the > SVN and keeps their branch up to date with the main SVN trunk as bugs are > fixed in trunk.
> When a feature branch is complete and stable, the code can be reviewed, > tested, and approved for release in the next feature release. Any number of > these branches can be worked on at one time. Obviously, there is the > potential for conflicts and we will need to coordinate efforts when people > want to work on overlapping functionality. If two groups are both working in > the same area of the code, for example, it might make sense for them to join > forces and work in a common branch. In other cases, two separate approaches > to the same problem might be tried by different groups and the best one > might be adopted into the package.
> After the last maintenance release, the features that are approved and > stable in the branches as of this time are merged into the trunk. At this > point, we have frozen the features and only these new features will be > included in the release. Others can continue to develop new features in > branches, but they will be for the next release.
> The last period of time is to get the new features ready for release. In > this example, we have from November 2 until December 31 to test the new > features, fix bugs, release a beta or release candidate version, and update > our documentation.
> *Other Observations*
> - The period of six months was picked for this proposal to illustrate > the point. The idea behind this proposal will also work with a longer cycle, > such as 12 months. > - It might make sense to designate some releases for long-term security > upgrades. For example, say that 1.6 releases March 31, 2010 and 1.7 releases > December 31, 2010. We could continue to provide security releases for 1.6 > for 1 – 2 years. So users would have the choice to upgrade to 1.7, 1.8, 1.9 > or to continue on 1.6 and eventually upgrade to 2.0. > - The scenario outlined above assumes we will merge feature branches > "just in time" for the next release. An alternative approach would be for > the project to maintain an "official" branch of approved, merged features > and merge new feature branches into this branch as soon as they are > approved. That way, there would be more time to test these features and > perhaps functional tests could be written for the new features as they are > added. > - The proposed cycle has a big advantage with respect to GSoC and GHOP. > Both of these programs offer the opportunity to get code written. However, > we don't have control over the timing of these contributions. For example, > this past summer was "too soon" for 1.6, since there wasn't a stable version > ready for most of the summer. But in another way it was "too late" for 1.6, > since we already had a quasi-freeze on new features (because people were > understandably worried about delaying it's release). Having a release cycle > where we can always accept code contributions and where we have a way to get > them into core in a reasonable timeframe could make it possible for us to > make better use of these contributions. > - Version end-of-life would occur 6 months after a new version is > released. For example, assume 1.8 is release on 1 July 2010. If 1.9 comes > out on 1 January 2011, then 1.8 would only be patched with security fixes > after this date up until 1 July 2011.
> -- > You received this message because you are subscribed to the Google Groups > "Joomla! General Development" group. > To post to this group, send an email to > joomla-dev-general@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-general+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> -- > You received this message because you are subscribed to the Google Groups > "Joomla! General Development" group. > To post to this group, send an email to > joomla-dev-general@googlegroups.com. > To
I agree with Gergo Erdosi: stable is more important than fast.
Each time a new version released, the user has to update their website. You know, you can't make all webmasters action at the same time. You should give some time to them for updating.
A fast released, buggy version is dangerous, too. It may bring new vulnerabilities to websites.
So, I think a new version should be tested over and over before release to public.
That is to say, a cycle of 6 months or longer is better than a shorter one.
Thanks Mark, this is certainly looking like the community will have more input freedom.
A couple of things that crossed my mind while reading:
- Try to make Labs a very easy to use one stop place with everything related to development. What I mean is a developer shouldn't have to go to different places for the bugtracker, API docs, google lists etc etc - Make sure the decision making process for what "is good enough" for core happens in the open and easy to find place from a helpful view like proposing changes that need to be made before approval.
Is the developer community asked for feedback on the actual Labs functionality somewhere? If not it might be smart to do that still early in the process and give a solid group early access to be able to test and give feedback.
The other thing to keep in mind is that the Ubuntu project is more of an aggregator (or even - sub-aggregator of the debian branches) - while there are certain core projects unique to ubuntu, new releases are actually more about coordinating a big slew of foreign packages. Similarly, after an ubuntu release, a wide variety of different domains within the system are updated through the built in packge manager.
I would say that for now, Joomla is a far more monolithic package and major releases are sure to get updates going, but minor releases can take much longer to catch on (I still find systems that have one of the early 1.5 versions installed).
So this is another reason why focus should be on the framework and stability, not fast releases and features.
Not sure that you cannot have a steady release cycle (even one of six months) though - I would say 6 months can be realistic if you have enough contributions and/or keep a rigid featureset. If you want to have a "big bang" of features with the next release, it is certainly unrealistic.
On Fri, Dec 18, 2009 at 8:58 AM, Gergo Erdosi <ge...@joomline.org> wrote: > Hi,
> I also like this proposal. There is only one thing I would change and it's > the time between releases. I think 6 months are not enough.
> 1. From the Joomla! project point of view: Even if we start the Labs site > and allow people to contribute easily, adding new features, testing and > documenting them is not easy. So I'm afraid we will have to postpone the > release date many times, or we will release an application with full of > bugs.
> 2. From the user / developer point of view: Again, this time is too short. > Developers have to update their extensions to work with the new release. > This can be started just after a Beta release. When developers update their > extensions (it can take month for a component), users can start updating > their sites, which will also take some time. And when they are finally > ready, the new release of Joomla is out and they can start the whole process > again.
> Ubuntu has a 6 months long release cycle, but first of all there is a much > larger community behind Ubuntu than behind Joomla, secondly many times a > stable release actually very unstable. So instead of releasing an unstable > CMS each time, I would suggest to spend some more time on it, for example > 9-12 months.
> I'm not sure this topic is about the strategy itself or about any part of > it. If the length of the release cycle is part of an other discussion, > please ignore this post.
> --- > Gergo Erdosi
> On 18 Dec 2009, at 03:34, Mark Dexter wrote:
> Hi everyone. Below is an outline of a new proposed release cycle for > Joomla. Please note that this is only a proposal at this point. This is > based on Louis Landry's ideas that the Dev Coordinators and Production Work > Group discussed at the NYC Dev Conference. If we adopt it, it would start > after version 1.6 is shipping and stable.
> We are excited about this idea and think it is a good direction for the > project. However, we need to hear what the community thinks about it. So, > please read it and let us know what you think! Thanks. Mark Dexter
> *Proposal for New Joomla! Release Cycle*
> *Background*
> Version 1.5 was released on 22 January 2008. As of this writing in December > 2009, version 1.6 is planned to release in Q1 or Q2 of 2010, more than two > years after version 1.5. This document proposes a process to shorten the > release cycle so that new Joomla! versions can be released more frequently, > for example every six months.
> *Objectives* > * * > The objectives of the proposed release cycle are:
> 1. Continue to offer a stable, reliable platform for our current and > future user base. > 2. Make new core features available to the community on a more timely > basis. > 3. Allow developers to write and contribute code to the project at any > time in the release cycle. > 4. Make it easier for community developers to contribute features to > the project. > 5. Make our release cycle more like other FOSS projects, such as > Eclipse and Ubuntu.
> *Executive Summary*
> The new strategy is based on four key practices.
> *Stable Trunk.* The main trunk of the SVN code repository will only be > updated in one of two ways: (1) from patches containing tested bug fixes > from the Bug Squad; (2) from merges from feature branches that have been > completed and approved by the development team. In this way, the main trunk > of the SVN will always contain a stable version that can be made ready for > release in a short time (for example, 30 – 60 days).
> "*Contract with Users". *Maintain a "contract" with users that says that > new Joomla! releases and new features will not break existing, documented > functionality. Because of this, users will be able to update their sites to > new releases as they become available, just like they have been able to do > with version 1.5 maintenance releases.
> *Date-Based Releases. *Release based on calendar dates, for example, every > 6 months. Features that are approved and ready in time for a release will be > included. Features that are not ready will not be included (but could be > included in the next release). > * * > *Open Development Environment. *Anyone who wants to will be able to create > an account, create an SVN branch, and start coding. The development team > will of course exercise final say on whether a feature gets included into > the core product. It is hoped that developers familiar with other FOSS > projects will find the process familiar and easy. > * * > *Example Scenario* > * * > For this example, we are releasing a maintenance release every 2 months and > a feature release every 6 months. The dates and version numbers are for > illustration only. > * * > Date > Activity > July 1 > Version 1.8.0 released. > July 15 > Group A completes feature in Branch A > August 5 > Group B completes feature in Branch B > July 1 – September 1 > Bug Squad commits patches to main SVN trunk > September 1 > Version 1.8.1 released > September 20 > Group C completes feature in Branch C > September 1 – November 1 > Bug Squad commits patches to main SVN trunk > November 1 > Version 1.8.2 released > November 2 > Branches A, B, C merged to trunk > November 2 – December 31 > Bug Squad commits patches to main SVN trunk > November 2 – December 31 > Testing, bug fixes on new features > November 15 > Group D completes feature in Branch D (this will wait for the next release > after 1.9.0) > January 1 > Version 1.9.0 released. > * * > In this scenario, we can have any number of individuals or groups working > on new features for Joomla. Each person or group works in a branch of the > SVN and keeps their branch up to date with the main SVN trunk as bugs are > fixed in trunk.
> When a feature branch is complete and stable, the code can be reviewed, > tested, and approved for release in the next feature release. Any number of > these branches can be worked on at one time. Obviously, there is the > potential for conflicts and we will need to coordinate efforts when people > want to work on overlapping functionality. If two groups are both working in > the same area of the code, for example, it might make sense for them to join > forces and work in a common branch. In other cases, two separate approaches > to the same problem might be tried by different groups and the best one > might be adopted into the package.
> After the last maintenance release, the features that are approved and > stable in the branches as of this time are merged into the trunk. At this > point, we have frozen the features and only these new features will be > included in the release. Others can continue to develop new features in > branches, but they will be for the next release.
> The last period of time is to get the new features ready for release. In > this example, we have from November 2 until December 31 to test the new > features, fix bugs, release a beta or release candidate version, and update > our documentation.
> *Other Observations*
> - The period of six months was picked for this proposal to illustrate > the point. The idea behind this proposal will also work with a longer cycle, > such as 12 months. > - It might make sense to designate some releases for long-term security > upgrades. For example, say that 1.6 releases March 31, 2010 and 1.7 releases > December 31, 2010. We could continue to provide security releases for 1.6 > for 1 – 2 years. So users would have the choice to upgrade to 1.7, 1.8, 1.9 > or to continue on 1.6 and eventually upgrade to 2.0. > - The scenario outlined above assumes we will merge feature branches > "just in time" for the next release. An alternative approach would be for > the project to maintain an "official" branch of approved, merged features > and merge new feature branches into this branch as soon as they are > approved. That way, there would be more time to test these features and > perhaps functional tests could be written for the new features as they are > added. > - The proposed cycle has a big advantage with respect to GSoC and GHOP. > Both of these programs offer the opportunity to get code written. However, > we don't have control over the timing of these contributions. For example, > this past summer was "too soon" for 1.6, since there wasn't a stable version > ready for most of the summer. But in another way it was "too late" for 1.6, > since we already had a quasi-freeze on new features (because people were > understandably worried about delaying it's release). Having a release cycle > where we can always accept code contributions and where we have a way to get > them into core in a reasonable timeframe could make it possible for us to > make better use of these
* If we can really use the power of a lot of developers, then a release cycle can for sure be shortened. * If we only put features in the release that are thoroughly tested, then the release will be stable. * If we demand backward compatibility (or eventually some legacy solution) as much as possible, then releases won't break much. * If we provide better ways to upgrade, also standard ways for extensions, then upgrading is no problem.
All this needs some people who are dedicated to reviewing, testing, communicating and merging. It is a basic requirement for this plan to succeed. So: we need some people who are willing to spend their time mainly on the development-work of others i.s.o. their own development- work. It might be a good idea to switch e.g. half of the people in this "core-group" every year.
>Hi everyone. Below is an outline of a new proposed release cycle for >Joomla. Please note that this is only a proposal at this point. This >is based on Louis Landry's ideas that the Dev Coordinators and >Production Work Group discussed at the NYC Dev Conference. If we >adopt it, it would start after version 1.6 is shipping and stable.
>We are excited about this idea and think it is a good direction for >the project. However, we need to hear what the community thinks >about it. So, please read it and let us know what you think! Thanks. >Mark Dexter
>Proposal for New Joomla! Release Cycle
>Background
>Version 1.5 was released on 22 January 2008. As of this writing in >December 2009, version 1.6 is planned to release in Q1 or Q2 of >2010, more than two years after version 1.5. This document proposes >a process to shorten the release cycle so that new Joomla! versions >can be released more frequently, for example every six months.
>Objectives
>The objectives of the proposed release cycle are:
>1. Continue to offer a stable, reliable platform for our current >and future user base. >2. Make new core features available to the community on a more >timely basis. >3. Allow developers to write and contribute code to the project >at any time in the release cycle. >4. Make it easier for community developers to contribute >features to the project. >5. Make our release cycle more like other FOSS projects, such as >Eclipse and Ubuntu.
>Executive Summary
>The new strategy is based on four key practices.
>Stable Trunk. The main trunk of the SVN code repository will only be >updated in one of two ways: (1) from patches containing tested bug >fixes from the Bug Squad; (2) from merges from feature branches that >have been completed and approved by the development team. In this >way, the main trunk of the SVN will always contain a stable version >that can be made ready for release in a short time (for example, 30 >- 60 days).
>"Contract with Users". Maintain a "contract" with users that says >that new Joomla! releases and new features will not break existing, >documented functionality. Because of this, users will be able to >update their sites to new releases as they become available, just >like they have been able to do with version 1.5 maintenance releases.
>Date-Based Releases. Release based on calendar dates, for example, >every 6 months. Features that are approved and ready in time for a >release will be included. Features that are not ready will not be >included (but could be included in the next release).
>Open Development Environment. Anyone who wants to will be able to >create an account, create an SVN branch, and start coding. The >development team will of course exercise final say on whether a >feature gets included into the core product. It is hoped that >developers familiar with other FOSS projects will find the process >familiar and easy.
>Example Scenario
>For this example, we are releasing a maintenance release every 2 >months and a feature release every 6 months. The dates and version >numbers are for illustration only.
>Date
>Activity
>July 1
>Version 1.8.0 released.
>July 15
>Group A completes feature in Branch A
>August 5
>Group B completes feature in Branch B
>July 1 - September 1
>Bug Squad commits patches to main SVN trunk
>September 1
>Version 1.8.1 released
>September 20
>Group C completes feature in Branch C
>September 1 - November 1
>Bug Squad commits patches to main SVN trunk
>November 1
>Version 1.8.2 released
>November 2
>Branches A, B, C merged to trunk
>November 2 - December 31
>Bug Squad commits patches to main SVN trunk
>November 2 - December 31
>Testing, bug fixes on new features
>November 15
>Group D completes feature in Branch D (this will wait for the next >release after 1.9.0)
>January 1
>Version 1.9.0 released.
>In this scenario, we can have any number of individuals or groups >working on new features for Joomla. Each person or group works in a >branch of the SVN and keeps their branch up to date with the main >SVN trunk as bugs are fixed in trunk.
>When a feature branch is complete and stable, the code can be >reviewed, tested, and approved for release in the next feature >release. Any number of these branches can be worked on at one time. >Obviously, there is the potential for conflicts and we will need to >coordinate efforts when people want to work on overlapping >functionality. If two groups are both working in the same area of >the code, for example, it might make sense for them to join forces >and work in a common branch. In other cases, two separate approaches >to the same problem might be tried by different groups and the best >one might be adopted into the package.
>After the last maintenance release, the features that are approved >and stable in the branches as of this time are merged into the >trunk. At this point, we have frozen the features and only these new >features will be included in the release. Others can continue to >develop new features in branches, but they will be for the next >release.
>The last period of time is to get the new features ready for >release. In this example, we have from November 2 until December 31 >to test the new features, fix bugs, release a beta or release >candidate version, and update our documentation.
>Other Observations
>The period of six months was picked for this proposal to illustrate >the point. The idea behind this proposal will also work with a >longer cycle, such as 12 months. >It might make sense to designate some releases for long-term >security upgrades. For example, say that 1.6 releases March 31, 2010 >and 1.7 releases December 31, 2010. We could continue to provide >security releases for 1.6 for 1 - 2 years. So users would have the >choice to upgrade to 1.7, 1.8, 1.9 or to continue on 1.6 and >eventually upgrade to 2.0. >The scenario outlined above assumes we will merge feature branches >"just in time" for the next release. An alternative approach would >be for the project to maintain an "official" branch of approved, >merged features and merge new feature branches into this branch as >soon as they are approved. That way, there would be more time to >test these features and perhaps functional tests could be written >for the new features as they are added. >The proposed cycle has a big advantage with respect to GSoC and >GHOP. Both of these programs offer the opportunity to get code >written. However, we don't have control over the timing of these >contributions. For example, this past summer was "too soon" for 1.6, >since there wasn't a stable version ready for most of the summer. >But in another way it was "too late" for 1.6, since we already had a >quasi-freeze on new features (because people were understandably >worried about delaying it's release). Having a release cycle where >we can always accept code contributions and where we have a way to >get them into core in a reasonable timeframe could make it possible >for us to make better use of these contributions. >Version end-of-life would occur 6 months after a new version is >released. For example, assume 1.8 is release on 1 July 2010. If 1.9 >comes out on 1 January 2011, then 1.8 would only be patched with >security fixes after this date up until 1 July 2011. >--
>You received this message because you are subscribed to the Google >Groups "Joomla! General Development" group. >To post to this group, send an email to joomla-dev-general@googlegroups.com. >To unsubscribe from this group, send email to >joomla-dev-general+unsubscribe@googlegroups.com. >For more options, visit this group at >http://groups.google.com/group/joomla-dev-general?hl=en-GB.
--
>Please keep the Subject wording in your answers
This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. ----------------------------------------------------------- Jean-Marie Simonet / infograf768 Joomla! Translation Coordination Team
@David and Herman: With the stable branch strategy you can for sure release anytime. But will developers and users be able to keep this time? Because I still can see many sites using Joomla 1.0 and it has been released 4 years ago. Now you expect that suddenly people will upgrade their sites twice a year? And think about developers, if the new release of Joomla causes incompatibility with the previous version, then they have to release a new version of the extension and it makes support and maintenance very hard. Thanks god Nooku Framework solves this problem, but think abut those who use the Joomla framework. Upgrading Ubuntu takes about half an hour, upgrading a Joomla site may take months.
> * If we can really use the power of a lot of developers, then a > release cycle can for sure be shortened. > * If we only put features in the release that are thoroughly tested, > then the release will be stable. > * If we demand backward compatibility (or eventually some legacy > solution) as much as possible, then releases won't break much. > * If we provide better ways to upgrade, also standard ways for > extensions, then upgrading is no problem.
> All this needs some people who are dedicated to reviewing, testing, > communicating and merging. It is a basic requirement for this plan to > succeed. So: we need some people who are willing to spend their time > mainly on the development-work of others i.s.o. their own development- > work. It might be a good idea to switch e.g. half of the people in > this "core-group" every year.
> --
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group. > To post to this group, send an email to joomla-dev-general@googlegroups.com. > To unsubscribe from this group, send email to joomla-dev-general+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
but I have some questions, and maybe is not only you, but more people here that can try think a bit more an answer it, because it demands knowledge about what was changed since Joomla 1.5 on joomla 1.6 SVN. And I'm sure that answering these question will be more obvious, even for who anser it, about one realistic release time, i.e. think about your Example Scenario like if it was implemented before.
My question is:
If instead of thinking in future, we try to think development of Joomla 1.6 like these Release Cycle, with same amount of developers, and with same amount of beta testers, almost same objectives to develop fist, what features we would expect each X months that we actually have on Joomla 1.6? id est, what we *have* in one imaginary release cycle in past of * 1.6 on june 2008 (or December 2008), * what on 1.7 on December 2008 (or June 2009) * what on 1.8 on June 2009 (or December 2010) ?
Ok, maybe is just one copy & paste from joomla 1.6 road map, but lets make who know how hard was to do each feature set one imaginary time to do it like release cycle style, and leave rest of who are reading here think one 'good time'. If we try rethink the past, will be more easy, since is possible know around how much time each feature was need to be developed/tested.
We just must remember that with release cycle, would be expected more people help a bit better, or even less frustrated than for example that recent case about include Beez again on core of 1.6. In this case, for example, I'm sure that have one great difference between do not include some code on actual release cycle ( that takes like 2~3 years) to one new release cycle of 6~12 months, AND, of course, if someone know that will not need so much time, will try code best possible to his code be accepted on next Joomla release and we will avoid thinks like almost one flame war with someone that want code for joomla and someone that know that can be a good feature, but include one more feature will delay more and more the next Joomla release.
> @David and Herman: With the stable branch strategy you can for sure release anytime. But will developers and users be able to keep this time? Because I still can see many sites using Joomla 1.0 and it has been released 4 years ago. Now you expect that suddenly people will upgrade their sites twice a year? And think about developers, if the new release of Joomla causes incompatibility with the previous version, then they have to release a new version of the extension and it makes support and maintenance very hard. Thanks god Nooku Framework solves this problem, but think abut those who use the Joomla framework. Upgrading Ubuntu takes about half an hour, upgrading a Joomla site may take months.
> --- > Gergo Erdosi
> On 18 Dec 2009, at 11:44, Herman Peeren wrote:
> > * If we can really use the power of a lot of developers, then a > > release cycle can for sure be shortened. > > * If we only put features in the release that are thoroughly tested, > > then the release will be stable. > > * If we demand backward compatibility (or eventually some legacy > > solution) as much as possible, then releases won't break much. > > * If we provide better ways to upgrade, also standard ways for > > extensions, then upgrading is no problem.
> > All this needs some people who are dedicated to reviewing, testing, > > communicating and merging. It is a basic requirement for this plan to > > succeed. So: we need some people who are willing to spend their time > > mainly on the development-work of others i.s.o. their own development- > > work. It might be a good idea to switch e.g. half of the people in > > this "core-group" every year.
> > --
> > You received this message because you are subscribed to the Google Groups "Joomla! General Development" group. > > To post to this group, send an email to joomla-dev-general@googlegroups.com. > > To unsubscribe from this group, send email to joomla-dev-general+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/joomla-dev-general?hl=en-GB.
I think making the upgrade process easier for users and developers is one of the most important things with highest priority. For at the moment one of the things I hear most from people not using Joomla! is that it would be so unsecure and that that is mostly due to unsecure extensions. If we want Joomla! to grow and stay secure, then we must have some good and easy rules concerning security and updates.
I'm also working in that direction and it will be my first project if the Lab swings open. I made an application for updating many sites (say 40 - 100) for all customers from one spot with just one push on the button; more for people like we, who make sites for customers that have little knowledge of that kind of maintenance. I think we can make something better if we could work on this with a group and set some standards and API's to force (don't hit me, I mean it in a gentle way; maybe better: invite) developers to adhere to it so security and ease of updates will be easy. I was working along the same lines as Sam's XML-files. Anyone wants to join me?
The time between releases hasn't been finalized (for that matter, neither has this decision, but it is something that we are discussing as the production working group leadership team and something that we have agreed upon in principle). We would ideally like to keep it fairly quick so that we can provide regular updates for administrators that want fresh and new features on a regular basis. The thought is to also do longer term releases that would have longer term support. That way, for sites where it makes more sense to keep the same core, they can do so knowing that they will be supported with security fixes for X amount of time.
The other aspect of things is that the amount of features that we would add to a release would likely be much less. As another poster mentioned, you wouldn't have this rush to try and get features ready by a certain date as much because you wouldn't have to fear that the next time around would be two or three years down the road. Missing the deadline for BETA 1.7 for your feature would mean not mean you have to wait two years for the next one.
New features then, don't have to get completed within the short six month cycle. Some features might take 8 months or a year to complete (either due to complexity or due to developer interest), but that would be okay because it is off in a branch being developed.
Testing is something we really need to work on. Automated testing will begin to play a bigger role in our release cycle as we prepare a solid platform that is easy and efficient for developers to use. We'll want to reshape JBS a little bit so that our time is used in a more concentrated fashion - more work type events which will probably focus around a release date.
In my experience, documentation happens at the end anyway. Being able to schedule when we'll need documentation resources will possibly make this easier to get in a timely manner. Right now there is a lot in terms of documentation that is waiting for BETA release. If we know when exactly that BETA release will happen, then planning that becomes a lot easier. With smaller incremental releases there will be less of a delta to redocument every time.
As per item 2, again, as our release cycle shortens, the delta between releases shrinks. What this means is that it isn't as big of an impact on developers and it takes less work for them to update their extensions. We've been working on testing tools for core, but my hope is also to be able to share some of the infrastructure that we developer for core with third party developers so that we can facilitate that process for them. I believe that by shortening our release cycle we will pull third party developers along with us.
Part of our hope with all of this is to make site updates much much easier. Sam's updater stuff means that we can make migration a much simpler task.
All that being said, 6 months may be too quick. The challenge and what we're grappling with is that we don't want our release times to coordinate with busy times in people's lives. So, for example, we wouldn't want to plan to do a major release on January 1st, because December tends to be busy for people and we are likely to hit resource shortages. By going with 6 months we can set times that are generally lower demand for people (hopefully) and can do that predictably. Going to a year would be an alternative but this may be too long between releases. If we go 8 months, say, then we might have a release in April, but then the next release would be December, which could be problematic. There may be other ideas worth exploring. I dunno.
Anyway, we really appreciate your constructive criticisms and concerns. *Please people, keep the questions and ideas and thoughts coming so that we can really make a wise decision on this.*
On Fri, Dec 18, 2009 at 2:58 AM, Gergo Erdosi <ge...@joomline.org> wrote: > Hi,
> I also like this proposal. There is only one thing I would change and it's > the time between releases. I think 6 months are not enough.
> 1. From the Joomla! project point of view: Even if we start the Labs site > and allow people to contribute easily, adding new features, testing and > documenting them is not easy. So I'm afraid we will have to postpone the > release date many times, or we will release an application with full of > bugs.
> 2. From the user / developer point of view: Again, this time is too short. > Developers have to update their extensions to work with the new release. > This can be started just after a Beta release. When developers update their > extensions (it can take month for a component), users can start updating > their sites, which will also take some time. And when they are finally > ready, the new release of Joomla is out and they can start the whole process > again.
> Ubuntu has a 6 months long release cycle, but first of all there is a much > larger community behind Ubuntu than behind Joomla, secondly many times a > stable release actually very unstable. So instead of releasing an unstable > CMS each time, I would suggest to spend some more time on it, for example > 9-12 months.
> I'm not sure this topic is about the strategy itself or about any part of > it. If the length of the release cycle is part of an other discussion, > please ignore this post.
> --- > Gergo Erdosi
> -- > You received this message because you are subscribed to the Google Groups > "Joomla! General Development" group. > To post to this group, send an email to > joomla-dev-general@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-general+unsubscribe@googlegroups.com<joomla-dev-general%2Bunsubs cribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
As Gergo said, keep 3PD's in mind. They need to upgrade their extensions. I think commercial 3PD's will have no real issue with this, but the others need some time (right?).
Also, I think its a good idea to think about the management of the branches/new features directly, not after this proposal is in affect. I mean: what features are going to be in core at all. At the moment I know it might seem that any features (created by other non-core devs like JoomlaWorks) should get in core, no wining, because its not happening now, but this will be an issue in the future.
I believe the community, all of us, should decide what features should be in, based on popularity, right. Then a team (or multiple teams) can do a proposal for that feature, and again the community decides what team will work on that proposal. A team could consist of a group of willing developers/companies.
It might be a solution if Joomla! Labs (still in the picture right?) would have a feature like uservoice (or use uservoice) so willing community members that find the way can vote here for a. features and b. proposals for a certain feature to be implemented by certain groups.
Off course I am interested in any reasons why the community voting for new features should not happen and be done by a workgroup or leadership team.
On Dec 18, 2:49 pm, Ian MacLennan <ian.maclen...@joomla.org> wrote:
> The time between releases hasn't been finalized (for that matter, neither > has this decision, but it is something that we are discussing as the > production working group leadership team and something that we have agreed > upon in principle). We would ideally like to keep it fairly quick so that > we can provide regular updates for administrators that want fresh and new > features on a regular basis. The thought is to also do longer term releases > that would have longer term support. That way, for sites where it makes > more sense to keep the same core, they can do so knowing that they will be > supported with security fixes for X amount of time.
> The other aspect of things is that the amount of features that we would add > to a release would likely be much less. As another poster mentioned, you > wouldn't have this rush to try and get features ready by a certain date as > much because you wouldn't have to fear that the next time around would be > two or three years down the road. Missing the deadline for BETA 1.7 for > your feature would mean not mean you have to wait two years for the next > one.
> New features then, don't have to get completed within the short six month > cycle. Some features might take 8 months or a year to complete (either due > to complexity or due to developer interest), but that would be okay because > it is off in a branch being developed.
> Testing is something we really need to work on. Automated testing will > begin to play a bigger role in our release cycle as we prepare a solid > platform that is easy and efficient for developers to use. We'll want to > reshape JBS a little bit so that our time is used in a more concentrated > fashion - more work type events which will probably focus around a release > date.
> In my experience, documentation happens at the end anyway. Being able to > schedule when we'll need documentation resources will possibly make this > easier to get in a timely manner. Right now there is a lot in terms of > documentation that is waiting for BETA release. If we know when exactly > that BETA release will happen, then planning that becomes a lot easier. > With smaller incremental releases there will be less of a delta to > redocument every time.
> As per item 2, again, as our release cycle shortens, the delta between > releases shrinks. What this means is that it isn't as big of an impact on > developers and it takes less work for them to update their extensions. > We've been working on testing tools for core, but my hope is also to be able > to share some of the infrastructure that we developer for core with third > party developers so that we can facilitate that process for them. I believe > that by shortening our release cycle we will pull third party developers > along with us.
> Part of our hope with all of this is to make site updates much much easier. > Sam's updater stuff means that we can make migration a much simpler task.
> All that being said, 6 months may be too quick. The challenge and what > we're grappling with is that we don't want our release times to coordinate > with busy times in people's lives. So, for example, we wouldn't want to > plan to do a major release on January 1st, because December tends to be busy > for people and we are likely to hit resource shortages. By going with 6 > months we can set times that are generally lower demand for people > (hopefully) and can do that predictably. Going to a year would be an > alternative but this may be too long between releases. If we go 8 months, > say, then we might have a release in April, but then the next release would > be December, which could be problematic. There may be other ideas worth > exploring. I dunno.
> Anyway, we really appreciate your constructive criticisms and > concerns. *Please > people, keep the questions and ideas and thoughts coming so that we can > really make a wise decision on this.*
> Ian
> On Fri, Dec 18, 2009 at 2:58 AM, Gergo Erdosi <ge...@joomline.org> wrote: > > Hi,
> > I also like this proposal. There is only one thing I would change and it's > > the time between releases. I think 6 months are not enough.
> > 1. From the Joomla! project point of view: Even if we start the Labs site > > and allow people to contribute easily, adding new features, testing and > > documenting them is not easy. So I'm afraid we will have to postpone the > > release date many times, or we will release an application with full of > > bugs.
> > 2. From the user / developer point of view: Again, this time is too short. > > Developers have to update their extensions to work with the new release. > > This can be started just after a Beta release. When developers update their > > extensions (it can take month for a component), users can start updating > > their sites, which will also take some time. And when they are finally > > ready, the new release of Joomla is out and they can start the whole process > > again.
> > Ubuntu has a 6 months long release cycle, but first of all there is a much > > larger community behind Ubuntu than behind Joomla, secondly many times a > > stable release actually very unstable. So instead of releasing an unstable > > CMS each time, I would suggest to spend some more time on it, for example > > 9-12 months.
> > I'm not sure this topic is about the strategy itself or about any part of > > it. If the length of the release cycle is part of an other discussion, > > please ignore this post.
> > --- > > Gergo Erdosi
> > -- > > You received this message because you are subscribed to the Google Groups > > "Joomla! General Development" group. > > To post to this group, send an email to > > joomla-dev-general@googlegroups.com. > > To unsubscribe from this group, send email to > > joomla-dev-general+unsubscribe@googlegroups.com<joomla-dev-general%2Bunsubs cribe@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/joomla-dev-general?hl=en-GB.
I applaud for the open way you put this discussion out there!
The discussion of improving release schedules is an old one, I remember discussing something close what you describe here during the development coordinator meeting in January and it for sure is not simple to put something like that in place.
I do not fully understand were you do maintenance releases, and new (major/minor) releases in this proposal. Can you explain that a bit more with a practical example (or how it differs from the current setup)?
No matter what strategy you put in place, the quality management will be key for succeeding with this proposed strategy. I very agree with the approach to have on stable trunk that is used for releases, basically the way it set up now. To be ready for a release at any time, you need to work towards a test driven development approach. In short this means you at least need the rules of the (coding) game in place (read: coding standards formalized and implemented), unit testing and preferable also automated end-user testing (like you can do with selenium) and from there move towards an environment where you have continuous integration in place.
The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices. When I started developing in open source we worked together with a group of open source (volunteer) developers, having some basic infrastructure like version control and informal coding guidelines in place. But every individual developer was responsible for the quality of the whole, resulting in various areas of the code-base to break after almost every commit. Within Joomla this problems still exists even with the Joomla Bug Squad acting as the main quality gate, but realize this is only for the current stable release and does not even apply to the 1.6 code-base (situation is worse in that regard).
An important part of any software development process is getting reliable builds of the software. Despite it's importance, we are often surprised when this isn't done. Within the Joomla project the quality of the CMS is maintained manually by a group of people, and I found out that this is a very time consuming in an environment where a simple fix in the software can break a lot of other areas. Many have blogged about (open source) tools are available to implement a continuous build environment. A mature CI environment stresses a fully automated and reproducible build, including testing, code analyses, API documentation and (if needed) package generation process that runs after every commit. One of the hardest things to express about continuous integration is that makes a *fundamental shift to the whole development pattern*, one that isn't easy to see if you've never worked in an environment that practices it. In fact most people do see this atmosphere if they are working solo - because then they only integrate with themselves. For many people team development just comes with certain problems that are part of the territory. Continuous integration reduces these problems, in exchange for a certain amount of discipline.
The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person's work has stepped on someone Else's work without either person realizing what happened. These bugs are hard to find because the problem isn't in one person's area, it is in the interaction between two pieces of work. This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves. As a result they take a lot of finding. Done right, it will enable you to release basically from any state of the trunk. If you put this in place, this strategy has much more chance to succeed. Implementing it can be done granular, and based upon the work already done on this area, it takes just a little more effort to get it fully implemented but it can be done, no doubt about that.
As proposed in earlier replies, I am more then willing to help setting up such an environment with the people who already do groundbreaking work on that area, let me know if my help is wanted.
Cheers, Wilco
On Fri, Dec 18, 2009 at 3:10 PM, David-Andrew <chillcreati...@gmail.com>wrote:
> As Gergo said, keep 3PD's in mind. They need to upgrade their > extensions. I think commercial 3PD's will have no real issue with > this, but the others need some time (right?).
> Also, I think its a good idea to think about the management of the > branches/new features directly, not after this proposal is in affect. > I mean: what features are going to be in core at all. At the moment I > know it might seem that any features (created by other non-core devs > like JoomlaWorks) should get in core, no wining, because its not > happening now, but this will be an issue in the future.
> I believe the community, all of us, should decide what features should > be in, based on popularity, right. Then a team (or multiple teams) can > do a proposal for that feature, and again the community decides what > team will work on that proposal. A team could consist of a group of > willing developers/companies.
> It might be a solution if Joomla! Labs (still in the picture right?) > would have a feature like uservoice (or use uservoice) so willing > community members that find the way can vote here for a. features and > b. proposals for a certain feature to be implemented by certain > groups.
> Off course I am interested in any reasons why the community voting for > new features should not happen and be done by a workgroup or > leadership team.
> On Dec 18, 2:49 pm, Ian MacLennan <ian.maclen...@joomla.org> wrote: > > Hey Gergo,
> > The time between releases hasn't been finalized (for that matter, neither > > has this decision, but it is something that we are discussing as the > > production working group leadership team and something that we have > agreed > > upon in principle). We would ideally like to keep it fairly quick so > that > > we can provide regular updates for administrators that want fresh and new > > features on a regular basis. The thought is to also do longer term > releases > > that would have longer term support. That way, for sites where it makes > > more sense to keep the same core, they can do so knowing that they will > be > > supported with security fixes for X amount of time.
> > The other aspect of things is that the amount of features that we would > add > > to a release would likely be much less. As another poster mentioned, you > > wouldn't have this rush to try and get features ready by a certain date > as > > much because you wouldn't have to fear that the next time around would be > > two or three years down the road. Missing the deadline for BETA 1.7 for > > your feature would mean not mean you have to wait two years for the next > > one.
> > New features then, don't have to get completed within the short six month > > cycle. Some features might take 8 months or a year to complete (either > due > > to complexity or due to developer interest), but that would be okay > because > > it is off in a branch being developed.
> > Testing is something we really need to work on. Automated testing will > > begin to play a bigger role in our release cycle as we prepare a solid > > platform that is easy and efficient for developers to use. We'll want to > > reshape JBS a little bit so that our time is used in a more concentrated > > fashion - more work type events which will probably focus around a > release > > date.
> > In my experience, documentation happens at the end anyway. Being able to > > schedule when we'll need documentation resources will possibly make this > > easier to get in a timely manner. Right now there is a lot in terms of > > documentation that is waiting for BETA release. If we know when exactly > > that BETA release will happen, then planning that becomes a lot easier. > > With smaller incremental releases there will be less of a delta to > > redocument every time.
> > As per item 2, again, as our release cycle shortens, the delta between > > releases shrinks. What this means is that it isn't as big of an impact > on > > developers and it takes less work for them to update their extensions. > > We've been working on testing tools for core, but my hope is also to be > able > > to share some of the infrastructure that we developer for core with third > > party developers so that we can facilitate that process for them. I > believe > > that by shortening our release cycle we will pull third party developers > > along with us.
> > Part of our hope with all of this is to make site updates much much > easier. > > Sam's updater stuff means that we can make migration a much simpler task.
> > All that being said, 6 months may be too quick. The challenge and what > > we're grappling with is that we don't want our release times to > coordinate > > with busy times in people's lives. So, for example, we wouldn't want to > > plan to do a major release on January 1st, because December tends to be > busy > > for people and we are likely to hit resource shortages. By going with 6 > > months we can set times that are generally lower demand for people > > (hopefully) and can do that predictably. Going to a year would be an > > alternative but this may be too long between releases. If we go 8 > months, > > say, then we might have a release in April, but then the next release > would > > be December, which could be problematic. There may be other ideas worth > > exploring. I dunno.
> > Anyway, we really appreciate your constructive criticisms and > > concerns. *Please > > people, keep the questions and ideas and thoughts coming so that we can > > really make a wise decision on this.*
> > Ian
> > On Fri, Dec 18, 2009 at 2:58 AM, Gergo Erdosi <ge...@joomline.org>
@David Andrew: I do not agree with the a "Vote in the feature for the next release" approach. I rather see a vision on what Joomla should be, and how it interacts with all the 3rd party developers before we start debating what goes into the core and what does'nt.
Joomla as it is now is build as a framework to enable other people to build websites and application on. The vision was a slick but powerfull framework, I have done presentations on this to explain it better (see http://www.slideshare.net/willebil/impact-of-a-cms-framework-change-h... such an old example).
With this I do not say the community should not be involved in this discussion, but before you make a juggernaut out of Joomla with features some people need, and others don't I rather move to a more modular approach, and the good thing basically all is in place within Joomla, it only should be combined.
What about the idea Joomla offering a backend application installation solution, you can point, click and install from application directories like the JED (not limiting it to only JED btw), create package profiles (like blog solution x, social option Y) and offer the end user the ease of installing what he needs, keeping the core slick and powerfull (and not to forget, maintainable)?
Regards, Wilco On Fri, Dec 18, 2009 at 3:10 PM, David-Andrew <chillcreati...@gmail.com>wrote:
> As Gergo said, keep 3PD's in mind. They need to upgrade their > extensions. I think commercial 3PD's will have no real issue with > this, but the others need some time (right?).
> Also, I think its a good idea to think about the management of the > branches/new features directly, not after this proposal is in affect. > I mean: what features are going to be in core at all. At the moment I > know it might seem that any features (created by other non-core devs > like JoomlaWorks) should get in core, no wining, because its not > happening now, but this will be an issue in the future.
> I believe the community, all of us, should decide what features should > be in, based on popularity, right. Then a team (or multiple teams) can > do a proposal for that feature, and again the community decides what > team will work on that proposal. A team could consist of a group of > willing developers/companies.
> It might be a solution if Joomla! Labs (still in the picture right?) > would have a feature like uservoice (or use uservoice) so willing > community members that find the way can vote here for a. features and > b. proposals for a certain feature to be implemented by certain > groups.
> Off course I am interested in any reasons why the community voting for > new features should not happen and be done by a workgroup or > leadership team.
> On Dec 18, 2:49 pm, Ian MacLennan <ian.maclen...@joomla.org> wrote: > > Hey Gergo,
> > The time between releases hasn't been finalized (for that matter, neither > > has this decision, but it is something that we are discussing as the > > production working group leadership team and something that we have > agreed > > upon in principle). We would ideally like to keep it fairly quick so > that > > we can provide regular updates for administrators that want fresh and new > > features on a regular basis. The thought is to also do longer term > releases > > that would have longer term support. That way, for sites where it makes > > more sense to keep the same core, they can do so knowing that they will > be > > supported with security fixes for X amount of time.
> > The other aspect of things is that the amount of features that we would > add > > to a release would likely be much less. As another poster mentioned, you > > wouldn't have this rush to try and get features ready by a certain date > as > > much because you wouldn't have to fear that the next time around would be > > two or three years down the road. Missing the deadline for BETA 1.7 for > > your feature would mean not mean you have to wait two years for the next > > one.
> > New features then, don't have to get completed within the short six month > > cycle. Some features might take 8 months or a year to complete (either > due > > to complexity or due to developer interest), but that would be okay > because > > it is off in a branch being developed.
> > Testing is something we really need to work on. Automated testing will > > begin to play a bigger role in our release cycle as we prepare a solid > > platform that is easy and efficient for developers to use. We'll want to > > reshape JBS a little bit so that our time is used in a more concentrated > > fashion - more work type events which will probably focus around a > release > > date.
> > In my experience, documentation happens at the end anyway. Being able to > > schedule when we'll need documentation resources will possibly make this > > easier to get in a timely manner. Right now there is a lot in terms of > > documentation that is waiting for BETA release. If we know when exactly > > that BETA release will happen, then planning that becomes a lot easier. > > With smaller incremental releases there will be less of a delta to > > redocument every time.
> > As per item 2, again, as our release cycle shortens, the delta between > > releases shrinks. What this means is that it isn't as big of an impact > on > > developers and it takes less work for them to update their extensions. > > We've been working on testing tools for core, but my hope is also to be > able > > to share some of the infrastructure that we developer for core with third > > party developers so that we can facilitate that process for them. I > believe > > that by shortening our release cycle we will pull third party developers > > along with us.
> > Part of our hope with all of this is to make site updates much much > easier. > > Sam's updater stuff means that we can make migration a much simpler task.
> > All that being said, 6 months may be too quick. The challenge and what > > we're grappling with is that we don't want our release times to > coordinate > > with busy times in people's lives. So, for example, we wouldn't want to > > plan to do a major release on January 1st, because December tends to be > busy > > for people and we are likely to hit resource shortages. By going with 6 > > months we can set times that are generally lower demand for people > > (hopefully) and can do that predictably. Going to a year would be an > > alternative but this may be too long between releases. If we go 8 > months, > > say, then we might have a release in April, but then the next release > would > > be December, which could be problematic. There may be other ideas worth > > exploring. I dunno.
> > Anyway, we really appreciate your constructive criticisms and > > concerns. *Please > > people, keep the questions and ideas and thoughts coming so that we can > > really make a wise decision on this.*
> > Ian
> > On Fri, Dec 18, 2009 at 2:58 AM, Gergo Erdosi <ge...@joomline.org> > wrote: > > > Hi,
> > > I also like this proposal. There is only one thing I would change and > it's > > > the time between releases. I think 6 months are not enough.
> > > 1. From the Joomla! project point of view: Even if we start the Labs > site > > > and allow people to contribute easily, adding new features, testing and > > > documenting them is not easy. So I'm afraid we will have to postpone > the > > > release date many times, or we will release an application with full of > > > bugs.
> > > 2. From the user / developer point of view: Again, this time is too > short. > > > Developers have to update their extensions to work with the new > release. > > > This can be started just after a Beta release. When developers update > their > > > extensions (it can take month for a component), users can start > updating > > > their sites, which will also take some time. And when they are finally > > > ready, the new release of Joomla is out and they can start the whole > process > > > again.
> > > Ubuntu has a 6 months long release cycle, but first of all there is a > much > > > larger community behind Ubuntu than behind Joomla, secondly many times > a > > > stable release actually very unstable. So instead of releasing an > unstable > > > CMS each time, I would suggest to spend some more time on it, for > example > > > 9-12 months.
> > > I'm not sure this topic is about the strategy itself or about any part > of > > > it. If the length of the release cycle is part of an other discussion, > > > please ignore this post.
> > > --- > > > Gergo Erdosi
> > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Joomla! General Development" group. > > > To post to this group, send an email to > > > joomla-dev-general@googlegroups.com. > > > To unsubscribe from this group, send email to > > > joomla-dev-general+unsubscribe@googlegroups.com<joomla-dev-general%2Bunsubs cribe@googlegroups.com><joomla-dev-general%2Bunsubs > cribe@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/joomla-dev-general?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups > "Joomla! General Development" group. > To post to this group, send an email to > joomla-dev-general@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-general+unsubscribe@googlegroups.com<joomla-dev-general%2Bunsubs cribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Just as somebody on the "user/evangelist/developer" end of things that also watches the massive amount of energy and time you guys pour into this project (the degree of which astonished me on joining the various lists), I offer this thought:
If I were you guys, I'd try to shoot the middle between long-term releases/support and the excessively rapid output schedule of say, WordPress.
My big concern would be that while it would be nice to see quicker incremental improvements, there's also a bigger ecosphere built around Joomla, and each release is disruptive to one degree or another. Also, every moment you guys spend dealing with "the ball" where it is now, is a moment you're not moving to where the ball is going to be in a year's time.
All things considered, I think you guys have done a pretty good job on this front; I wouldn't personally advocate that you try to speed yourselves up too much without first securing additional manpower.
As to the specific methodologies some of you are discussing, I'd simply mention that the community has to work with what its got, not what it would like to have; as such, I imagine it'd be most useful to try to work backwards from "what Joomla already has" to "what can be done within those constraints to improve efficiencies."
That said, I wish you all Happy Holidays, and thank you all for a strong 2009!
** Personal note: I am actively seeking any non-pure-coding opportunities to help the project that can be accomplished in tiny bites throughout every day. So far, I've been looking at the Cookie Jar, but haven't had a chance to really get started on it yet. Any folks with better ideas are cordially invited to holler at me privately. :)
I like the idea of some type of Date-based releases. That approach as compatible with quality since the release includes only that which is ready. Building and following a schedule should help build in predictability and that helps everyone, perhaps most especially "the enterprise."
The more regular, scheduled releases should also help community not be as anxious about whether or not a specific feature will be included. If the wait is 2 years, then, it does become more of an issue. If it's every six months, obviously things get a lot more flexible.
It's great to see Arlen and Ian, and others, working on the Unit testing. That foundation is a key to these ideas working.
On Dec 18, 8:44 am, Wilco Jansen <jansen.wi...@gmail.com> wrote:
> As proposed in earlier replies, I am more then willing to help setting up > such an environment with the people who already do groundbreaking work on > that area, let me know if my help is wanted.
> Cheers, Wilco
Somebody, give that man a shovel and put him back to work! ;-)
Thanks for continuing to find ways to broaden out involvement. The ideas on branches are very good.
Very pleased with these ideas and appreciate the invitation to comment. Amy
First, I want to observe that one of the many contributing factors to the long interval between 1.5 and 1.6 was due to the relatively slow uptake of the 3PD community. The change between 1.0 and 1.5 was quite significant and the learning curve certainly slowed the transition. We won't be facing a shift like that for some time, so we can expect the 3P developer community to respond more quickly in the future. We can expect the minor release cycle to shorten no matter how we approach this.
At the same time, there is significant functionality that remains to be implemented, and I feel we need a mechanism to help extension developers keep pace with the changes.
Therefore I think we should consider the convention of making odd numbered minor releases "development" releases. The intent of this is to give 3PD's relatively stable "preview" releases without putting the burden of "relatively" on end users. An odd numbered release wouldn't guarantee a stable API, where an even numbered release would. As an example, let's say we implement content versioning and workflow in the next minor release. With the odd/even strategy, we would put this into a 1.7 (development) stream. This makes "stable" functionality available to 3PDs ahead of the general user base, so they have time to work with it.
We can have two outcomes: 1) We might "nail" the requirements in 1.7, have a body of happy 3PDs, and a set of extensions that are ready to go at the same time as 1.8 is available. This means that the 1.8 cycle can be accelerated.
2) 3PD feedback may demonstrate that 1.7.0 didn't get it quite right and that the API should be restructured. We listen, agree, and make changes that we release as 1.7.1. Rinse and repeat as required. Our "cutting edge" 3PDs will be happy because we listened to them and responded to their needs, and the 1.8 release will be better for it. We also provide a more functional and stable API to the rest of the 3PD community.
It would have been nice to do this with something significant like ACL, because a lot of users won't care much about this significant feature if extensions take 6 months before they really support it.
This approach is compatible with a scheduled release strategy, given that we hold to it with the "public" releases. The "development" releases can come when they're ready. In an ideal world, the public release is little more than giving a stable development release a new number (eg. 1.7.5 + minor fixes == 1.8.0).
On Dec 17, 10:34 pm, Mark Dexter <dextercow...@gmail.com> wrote:
> Hi everyone. Below is an outline of a new proposed release cycle for Joomla. > Please note that this is only a proposal at this point. This is based on > Louis Landry's ideas that the Dev Coordinators and Production Work Group > discussed at the NYC Dev Conference. If we adopt it, it would start after > version 1.6 is shipping and stable.
> We are excited about this idea and think it is a good direction for the > project. However, we need to hear what the community thinks about it. So, > please read it and let us know what you think! Thanks. Mark Dexter
> *Proposal for New Joomla! Release Cycle*
> *Background*
> Version 1.5 was released on 22 January 2008. As of this writing in December > 2009, version 1.6 is planned to release in Q1 or Q2 of 2010, more than two > years after version 1.5. This document proposes a process to shorten the > release cycle so that new Joomla! versions can be released more frequently, > for example every six months.
> *Objectives*
> * *
> The objectives of the proposed release cycle are:
> 1. Continue to offer a stable, reliable platform for our current and > future user base. > 2. Make new core features available to the community on a more timely > basis. > 3. Allow developers to write and contribute code to the project at any > time in the release cycle. > 4. Make it easier for community developers to contribute features to the > project. > 5. Make our release cycle more like other FOSS projects, such as Eclipse > and Ubuntu.
> *Executive Summary*
> The new strategy is based on four key practices.
> *Stable Trunk.* The main trunk of the SVN code repository will only be > updated in one of two ways: (1) from patches containing tested bug fixes > from the Bug Squad; (2) from merges from feature branches that have been > completed and approved by the development team. In this way, the main trunk > of the SVN will always contain a stable version that can be made ready for > release in a short time (for example, 30 – 60 days).
> "*Contract with Users". *Maintain a "contract" with users that says that new > Joomla! releases and new features will not break existing, documented > functionality. Because of this, users will be able to update their sites to > new releases as they become available, just like they have been able to do > with version 1.5 maintenance releases.
> *Date-Based Releases. *Release based on calendar dates, for example, every 6 > months. Features that are approved and ready in time for a release will be > included. Features that are not ready will not be included (but could be > included in the next release).
> * *
> *Open Development Environment. *Anyone who wants to will be able to create > an account, create an SVN branch, and start coding. The development team > will of course exercise final say on whether a feature gets included into > the core product. It is hoped that developers familiar with other FOSS > projects will find the process familiar and easy.
> * *
> *Example Scenario*
> * *
> For this example, we are releasing a maintenance release every 2 months and > a feature release every 6 months. The dates and version numbers are for > illustration only.
> * *
> Date
> Activity
> July 1
> Version 1.8.0 released.
> July 15
> Group A completes feature in Branch A
> August 5
> Group B completes feature in Branch B
> July 1 – September 1
> Bug Squad commits patches to main SVN trunk
> September 1
> Version 1.8.1 released
> September 20
> Group C completes feature in Branch C
> September 1 – November 1
> Bug Squad commits patches to main SVN trunk
> November 1
> Version 1.8.2 released
> November 2
> Branches A, B, C merged to trunk
> November 2 – December 31
> Bug Squad commits patches to main SVN trunk
> November 2 – December 31
> Testing, bug fixes on new features
> November 15
> Group D completes feature in Branch D (this will wait for the next release > after 1.9.0)
> January 1
> Version 1.9.0 released.
> * *
> In this scenario, we can have any number of individuals or groups working on > new features for Joomla. Each person or group works in a branch of the SVN > and keeps their branch up to date with the main SVN trunk as bugs are fixed > in trunk.
> When a feature branch is complete and stable, the code can be reviewed, > tested, and approved for release in the next feature release. Any number of > these branches can be worked on at one time. Obviously, there is the > potential for conflicts and we will need to coordinate efforts when people > want to work on overlapping functionality. If two groups are both working in > the same area of the code, for example, it might make sense for them to join > forces and work in a common branch. In other cases, two separate approaches > to the same problem might be tried by different groups and the best one > might be adopted into the package.
> After the last maintenance release, the features that are approved and > stable in the branches as of this time are merged into the trunk. At this > point, we have frozen the features and only these new features will be > included in the release. Others can continue to develop new features in > branches, but they will be for the next release.
> The last period of time is to get the new features ready for release. In > this example, we have from November 2 until December 31 to test the new > features, fix bugs, release a beta or release candidate version, and update > our documentation.
> *Other Observations*
> - The period of six months was picked for this proposal to illustrate the > point. The idea behind this proposal will also work with a longer cycle, > such as 12 months. > - It might make sense to designate some releases for long-term security > upgrades. For example, say that 1.6 releases March 31, 2010 and 1.7 releases > December 31, 2010. We could continue to provide security releases for 1.6 > for 1 – 2 years. So users would have the choice to upgrade to 1.7, 1.8, 1.9 > or to continue on 1.6 and eventually upgrade to 2.0. > - The scenario outlined above assumes we will merge feature branches > "just in time" for the next release. An alternative approach would be for > the project to maintain an "official" branch of approved, merged features > and merge new feature branches into this branch as soon as they are > approved. That way, there would be more time to test these features and > perhaps functional tests could be written for the new features as they are > added. > - The proposed cycle has a big advantage with respect to GSoC and GHOP. > Both of these programs offer the opportunity to get code written. However, > we don't have control over the timing of these contributions. For example, > this past summer was "too soon" for 1.6, since there wasn't a stable version > ready for most of the summer. But in another way it was "too late" for 1.6, > since we already had a quasi-freeze on new features (because people were > understandably worried about delaying it's release). Having a release cycle > where we can always accept code contributions and where we have a way to get > them into core in a reasonable timeframe could make it possible for us to > make better use of these
> As Gergo said, keep 3PD's in mind. They need to upgrade their > extensions. I think commercial 3PD's will have no real issue with > this, but the others need some time (right?).
The flip side to that is if devs know when the new release is coming they can plan in advance rather than working with a moving target. It's also possible that the new version has no effect of their extension as well. And another possibility if nothing is ready at the next abort-point, we just skip the version - it's not a big deal.
> Off course I am interested in any reasons why the community voting for > new features should not happen and be done by a workgroup or > leadership team.
It depends on what you are voting for. Asking the wider community to vote for the features they want is not a good idea because it doesn't follow that there are people able to or willing to do the work. Voting on which "completed" features should go in where you have an unusually high number of choices is something else. Voting on a "theme" for a release is also a possibility. But the problem question is always, who gets to vote: anyone, those who have done the work, the dev community, etc?
> @David Andrew: I do not agree with the a "Vote in the feature for the next > release" approach. I rather see a vision on what Joomla should be, and how > it interacts with all the 3rd party developers before we start debating what > goes into the core and what does'nt.
I agree. People should be allowed to work on whatever they want, but I see an agreed or set theme or vision for the next version being more helpful for everyone involved. For example, it's been loosely suggested that 1.7 is the CCK release, 1.8 is for bolstering social networking tools, etc. Always better to shoot for a common target. It, of course, doesn't preclude non-theme features being included.
2009/12/18 Arno Zijlstra <arno.alva...@gmail.com>:
> - Try to make Labs a very easy to use one stop place with everything > related to development. What I mean is a developer shouldn't have to > go to different places for the bugtracker, API docs, google lists etc > etc
This mailing list will remain, but the plan is to have that all in one place in the long term. Wanna help? :)
> - Make sure the decision making process for what "is good enough" for > core happens in the open and easy to find place from a helpful view > like proposing changes that need to be made before approval.
Do you have any suggestions?
> Is the developer community asked for feedback on the actual Labs > functionality somewhere? If not it might be smart to do that still > early in the process and give a solid group early access to be able to > test and give feedback.
Since Labs is an integral part of the proposal, this is the appropriate place to ask any questions.
But to summarise, Labs is just a new SVN repository with automated sign-up capability. Think about it as the equivalent of the Documentation Wiki only for code. Only the trunk and official Joomla releases are locked down, the rest is open for anyone to create branches or work in their own "home" folders on other experiments. If you want more privacy, the next step up is JoomlaCode or your own code repo or a hosted solution like CVSDude. There's really not much to it. The major change is you won't have to bug Sam or Mark to give you access to a branch anyone. ++'s all round.
On Fri, Dec 18, 2009 at 6:44 AM, Wilco Jansen <jansen.wi...@gmail.com>wrote:
> I do not fully understand were you do maintenance releases, and new > (major/minor) releases in this proposal. Can you explain that a bit more > with a practical example (or how it differs from the current setup)?
Wilco, the biggest difference with the current approach (as I understand it) is that the SVN trunk will be the current release (for example, 1.6.2) with up to date bug fixes and the branches will be copies of that trunk with whatever features are being added in the branch. Any new features will have to be added in a way that can be merged back into trunk without breaking existing functionality. At the present time, the trunk is totally separate from the 1.5.x release branch. And, as you know, the 1.6 features were not implemented in a backwards-compatible way (although we are trying very hard to make the 1.6 version functionally backwards compatible).
So, in the example I gave in the original post, the 1.8.1 and 1.8.2 maintenance releases come right out of trunk, with only bug fixes. The 1.9.0 release also comes out of trunk, but it has features merged from branches A, B, and C as well as any bug fixes since 1.8.2.
Also, it might make sense to have an official "latest stable" branch that contains bug fixes plus features that have already been merged in from feature branches. This could allow us to merge approved features in at any point in the release cycle, and keep these features in a ready state for the next dot release.
