Possible New Release Cycle for Joomla!

[Mark Dexter]

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.

[Airton Torres]

Hello Mark,

 

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.

 

You have my yes to that.

--

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-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[OnTheMarkDesign]

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

[Christophe Demko]

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.

Ch.D

[Gergo Erdosi]

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

[saurabh shah]

Hi,

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.

Goodluck !

2009/12/18 Gergo Erdosi <ge...@joomline.org>

--
Thanks & Regards,
Saurabh Shah
Web Developer | Web Designer | Freelancer
http://www.designstudio16.com
Contact - +91- 9970931101

[joomlagate.com]

Hi, all,

 

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.

 

Joomlagate

 

http://www.joomlagate.com/

.

[Arno Zijlstra]

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.

[David Deutsch]

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.

David Deutsch
valanx.org

[Herman Peeren]

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

[JM Simonet]

Looks fine, Mark

Obviously the 2 months release forecasted between minor updates may be changed depending on security issues.

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-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@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 

[Gergo Erdosi]

@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

[fititnt]

Great idea, Mark Dexter,

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.

--
Emerson da Rocha Luiz
eme...@webdesign.eng.br
http://www.fititnt.org | twitter @fititnt

[Herman Peeren]

@Gergo, about updating/upgrading

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.

Pasamio is working in this direction, as you without doubt will have
seen on the video of the JDC (BTW there is a better video from that on
http://zunostudios.com/blogs/Joomla-16-Extensions-Upate-System.html)
and for sure you know his JUpdateman.

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?

[Ian MacLennan]

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

[David-Andrew]

Great proposal!

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.

> concerns.  *Please

> people, keep the questions and ideas and thoughts coming so that we can

> really make a wise decision on this.*

> > joomla-dev-gene...@googlegroups.com<joomla-dev-general%2Bunsubs cr...@googlegroups.com>

[Wilco Jansen]

Hi Mark,

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

To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[Wilco Jansen]

@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-holland-open-netherlands-presentation for 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 <chillcr...@gmail.com> wrote:

To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[Brandon]

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. :)

--
Brandon Dawson
Athena Internet
Joomla & Wordpress CMS Website Design & Hosting
740.994.0088 :: 877.949.0088
bra...@athenainternet.com
http://www.athenainternet.com

[Amy Stephen]

Mark -

Thanks for your call for input!

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

[Alan (instance)]

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

> * *

> * *

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

[Andrew Eddie]

2009/12/18 David-Andrew <chillcr...@gmail.com>:

> Great proposal!
>
> 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?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Andrew Eddie]

2009/12/18 Wilco Jansen <jansen...@gmail.com>:

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

[Andrew Eddie]

2009/12/18 Arno Zijlstra <arno.a...@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.

[Mark Dexter]

On Fri, Dec 18, 2009 at 6:44 AM, Wilco Jansen <jansen...@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.

Mark

P.S. What a great discussion, everyone!

[Mitch Pirtle]

First a huge thanks to Mark for starting the discussion, and a second
thanks to everyone participating. In the past these decisions were
usually made in the deepest hours of the night with very little
confidence. Remember Mambo 4.5.1a folks? *giggle*

I'd like to offer only a simple twist to how Joomla regards releases.
Right now we have a major release and immediately lock it down for new
features, and then a huge monolithic march to the next major release.
I'd love to see the project push out a release, and feel comfortable
moving up minor releases frequently and saving the real
compatibility-busters for major releases.

For example, in an alternate universe Joomla might have evolved like
this: First came 1.0.0, then all the bugfixes and tweaks as 1.0.1,
1.0.2 and so on, with additional features (that didn't introduce
compatibility issues) released as minors like 1.1, 1.2, and so on.
What we now call 1.5 should have been 2.0, with all the maintenance
releases being 2.0.1, 2.0.2, etc. What we now call 1.6 probably would
be either 2.1 or 3.0 in this scenario, based on how well compatibility
turns out at the end of the development cycle.

IMHO going from 1.5 to 1.6 should not be viewed as a major upgrade,
nor should it introduce a host of compatibility issues. That said,
we're not really using version numbering like we should, and it would
be great if we got back to major/minor/maintenance numbering.

What I'm really trying to stress is the freeze in feature development
once a major release comes out - once 1.5 came out it was effectively
dead, as it was in maintenance mode. Might we benefit from a different
approach?

-- Mitch

[Andrew Eddie]

Alan, I really like where your thoughts are going here. Definitely a
suggestion to consider.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2009/12/18 Alan (instance) <alan.l...@abivia.com>:

[Joseph LeBlanc]

On Dec 18, 2009, at 2:25 PM, Mitch Pirtle wrote:

> I'd like to offer only a simple twist to how Joomla regards releases.
> Right now we have a major release and immediately lock it down for new
> features, and then a huge monolithic march to the next major release.
> I'd love to see the project push out a release, and feel comfortable
> moving up minor releases frequently and saving the real
> compatibility-busters for major releases.
>
> For example, in an alternate universe Joomla might have evolved like
> this: First came 1.0.0, then all the bugfixes and tweaks as 1.0.1,
> 1.0.2 and so on, with additional features (that didn't introduce
> compatibility issues) released as minors like 1.1, 1.2, and so on.
> What we now call 1.5 should have been 2.0, with all the maintenance
> releases being 2.0.1, 2.0.2, etc. What we now call 1.6 probably would
> be either 2.1 or 3.0 in this scenario, based on how well compatibility
> turns out at the end of the development cycle.
>
> IMHO going from 1.5 to 1.6 should not be viewed as a major upgrade,
> nor should it introduce a host of compatibility issues. That said,
> we're not really using version numbering like we should, and it would
> be great if we got back to major/minor/maintenance numbering.
>

Bingo. Even though WordPress comes out with releases approximately every 6 months (give or take a month), the upgrades within a major version rarely break the published APIs. Heck, they're not even considering dropping PHP 4 support until at least 90% of their userbase is on 5. I started two WordPress blogs on 2.5 and have upgraded them all the way through 2.8 with only minor adjustments to my theme. Also, WordPress seems to stop releasing patches for minor releases after a new minor release is made for the same version. They came out with 2.7.1, which was followed by 2.8, but there have been no further releases for 2.7.x: the way to patch is to upgrade to 2.8.6.

I've received comments from people outside the Joomla community saying "hey, you guys really shouldn't be breaking APIs on minor releases." I've tried to explain that our numbering is more "feature related," but that's really a fuzzy criteria to begin with.

Which brings us the root of the issue here: the biggest problem we have is with promising specific features for specific releases. For instance, we'll say "1.6 will handle ACL, X, Y, & Z," then feel obligated to delay Joomla 1.6 until ACL, X, Y, & Z are 100% complete. In the meantime, dozens of smaller (but still useful) features never make it in, because the release managers are tied up with testing and vetting the patches for ACL, X, Y, & Z. Patch contributors get frustrated and/or bored, then move on.

Moving towards a short-cycle, minor release schedule will be a huge benefit to Joomla. It will shorten the feedback cycle from the community at large and gradual improvements will get rolled in.

-Joe

[Joseph LeBlanc]

On Dec 18, 2009, at 6:17 PM, Joseph LeBlanc wrote:

> Bingo. Even though WordPress comes out with releases approximately every 6 months (give or take a month), the upgrades within a major version rarely break the published APIs. Heck, they're not even considering dropping PHP 4 support until at least 90% of their userbase is on 5. I started two WordPress blogs on 2.5 and have upgraded them all the way through 2.8 with only minor adjustments to my theme. Also, WordPress seems to stop releasing patches for minor releases after a new minor release is made for the same version. They came out with 2.7.1, which was followed by 2.8, but there have been no further releases for 2.7.x: the way to patch is to upgrade to 2.8.6.
>

EDIT: Make that WordPress 2.5 all the way through 2.9. :)

-Joe

[Beat]

Hi Mark and all,
Thanks for pushing forward the nice plan and doing a great Community
discussion, thanks also to everyone who participated.
As I have now access to this group, I'm moving my feedbacks to the
blog post into here, and completing them:

The plan looks nice on paper, aka screen. Let's see how it gets
converted *uncomplicated* into reality, *without forms, additional
contracts, and lawyers involved* (I am serious on that last one, as
any additional hassle would kill that great opening initiative).

As already said many times, *stability of the API* is key for
extensions devs.

So I would suggest a minor amendment:

Instead of merging new features into trunk *just before* a release
gets out, merge them into the trunk *just after* a release goes out.
That will leave a 2 or 6 months cycle to stabilize them and more
importantly any API regressions they may have onto existing
compatibility. It will relieve stress from Joomla core, bugs-squad and
extension developers.

Another small suggestion:

Open a *bugs-fixes* branch that is open writably to all major
extensions developers as well and gets reviewed and merged into trunk
regularly, the current back-log and unability to help getting tested
confirmed patches committed is frustrating. Not to mention that
patches are a real pain, compared to easy and more fun svn commits.

Then you can review that bugs-fixes branch and merge it easier into
trunk, than reviewing patches (which are a pain).

Also add a design process for the features, where design can be
discussed *before* implementation, and not after implementation. That
will save another considerable time loss, and foster participation.
Most professional devs will probably happily contribute code and free
time, if the design is agreed upon, but wasting time in developing
something where the implemented design is different from what the core
team wanted in the first place, or the coding style is different,
turns out to be a major issue, and actually probably is the major
blocker for having the GSOC making it into the Joomla trunk.

Reading features creep into core, I'm getting afraid of Joomla core
becoming too big and possibly slow if all dream features are really
integrated.

Joomla has a great extensions system, and an awesome new installer in
1.6, so we should really keep it modular: new features should be
implemented as independent components as much as possible, and not
throughout core. You could imagine official Joomla extensions, which
are not installed by default, so that core joomla application gets
slick, but framework is there to support many dream features.

Framework features is another thing, but it could be time to slim down
the core applications to only core features in one of next releases
actually.

E.g. new features should be independent components, modules and
plugins, and only generic core library API becoming part of Joomla
core.

Best Regards,
Beat
http://www.joomlapolis.com/

[ssnobben]

Beat, I dont understand part of the logic of what you are saying here
regarding a better system for Joomla as a whole.

"..the new features should be implemented as independent components as
much as possible, and not throughout core..."

Who is it better for and why?

I don't think this is a good idea if you have many features that
should normally belong to the core to make them "independent
components as much as possible" Wouldn't it be better to put them into
the core and make them to fit better and to be better customized to
fit the need of end users needs. Its a balance of course.

Maybe you can better explain why this would be a better and more
stable system for end users instead of have many standardized core
futures options? Will it not bring more interoperability problems and
bugs and a heavier burden for all what you are saying here? Isn´t
that why we should do, like Drupal is doing now with one example their
CCK? They put it into the core and then all fine tune it and make it
better all the time for performance, interoperability and quality.

Maybe the question for the community is what should be part of the
core and what should not - so there is no "interest of conflicts".

This make me thinking of the problems before like the SEO problems
that Joomla had maybe bcs of some "interest conflicts" or what ever?
Shouldn't that be part of Joomla core or should we have 5 different
solutions for that problem that always was a standard solution for
Drupal? Why I mention it is bcs I have seen this discussions in Joomla
forum before regarding the SEO problems of Joomla but I dont know what
is true or not.

So why would a system where you have 8 independent different cck
system gain Joomla and 3pds time and efforts?

That´s a trend that happening now for Joomla and Drupal moving to the
opposite to implement all basic features and core building blocks for
easier maintenance.