Hi everyone. Now that version 1.6.3 is released, the development focus for Joomla can shift gears and we can focus on new features for version 1.7. This is a very exciting time for the project, and the Production Leadership Team (PLT) thought it would be helpful to outline our ideas about the process for adding new features.

 

First a couple of caveats. As you may know, we have just switched to a time-based release cycle. So version 1.7 will be our first version that is released at a specific point in time – July 10, 2011 – instead of when a given set of features is complete. So we know when version 1.7 will release, but we don't know what new features it will contain. Because this is our first cycle of this type, we will be figuring some stuff out as we go along. We have the general outline of the process, as will be explained here, but there will no doubt be things that we need to adjust or change.

A second wrinkle is that, on or about 30 April 2011, we will split off the Joomla Platform (the libraries folder more or less) as a separate project. This will change the way in which we fix bugs and add features that affect the platform. Again, this is all new, so again we will be learning as we go along.

Time Line

That being said, we do have a pretty good outline of how we think the process for adding features for version 1.7 will work. First of all, here is the planned time line.

19 April 2011 Version 1.6.3 released. Trunk is frozen.
19 – 30 April 2011 Joomla Platform merged into CMS as external library
30 April 2011 Platform project launches. CMS trunk uses version 11.1 of the Platform.
14 Apr – 20 May 2011 Community gets new features ready, either in branches or in patches
1 May – 31 May 2011 New features added to trunk
1 June 2011 New feature freeze. No more features for 1.7. (But you only have to wait 5 months!)
1 June – 30 June 2011 Test, debug, and document new features
10 July 2011 Version 1.7.0 released

What does this mean for you? The important thing is this: now is the time to be working on new features for 1.7.

How Do I Contribute a New Feature?

The basic outline of contributing to Joomla is explained here: https://developer.joomla.org/getting-started.html#contributing. For small features, you can do patches. For larger features, setting up a branch is recommended.

It is very important to communicate via the CMS list what you plan to work on and try, if possible, to coordinate with others who are interested in working on the same area. We don't plan to try to manage this process in a top-down manner. We are hoping that members of the community will try to self-organize as much as possible.

Once a feature is in progress, we will track it in the Joomla Feature tracker (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549). When it is ready to go, we will try to find someone to help test and evaluate it and then get it ready for adding to trunk.

Who Will Decide What Features Get Added?

The PLT will have the final say in this. However, interest from the community will be an important consideration in the decision.

What Criteria Will Be Used For This Decision?

Here are the criteria we plan to use to decide whether a feature will be included.

1. Does the feature need to be in core?

Most functionality in the Joomla universe exists in extensions, and this is the way it should be. In general, the core should be as small as possible, as long as strong implementations of fundamental features are included. If you have a great idea, but it doesn't need to be in core, then you should probably develop it as an extension.

2. Does the feature pass automated tests?

If a feature changes existing functionality in the CMS, it needs to include automated system tests to demonstrate this functionality and prove that it works. If if doesn't change any existing functionality, then the existing system tests need to pass. If new functionality is added, system tests that test this new functionality should be included if applicable.

3. Does the code meet the Joomla coding standards?

Coding standards are currently being finalized. Until new standards are published, please use the existing standards.

4. Is the feature desirable?

Is the feature related to one of the top ideas in the Ideas Pool? Does it relate to the general goals for the release? (Recall that the theme for the version 1.7 release is Rediscover Content.) Is the feature something people have asked for in the past? Is there support for the idea on the CMS list?

5. Is the implementation architecturally sound?

Is the feature implemented in a way that makes sense in the context of the overall Joomla architecture? As part of the discussion and planning process on list, it is a great idea to discuss exactly how the feature will be implemented. This will help ensure that it fits well with the existing structure.

6. Is the feature documented?

It is very important to have at least basic documentation for what the feature does and how it works. Otherwise, it will be very difficult for anyone to evaluate the feature. Also, this documentation will be used for testing and for writing the Joomla help screens and any related tutorials.If a proposed feature meets these criteria and is ready on time, it will have a great chance to be included in the 1.7 release. If a feature is close but needs more work, then it can be re-submitted either for 1.7 (if there is still time) or the next release.

Final Thoughts

Here are some final points. As discussed above, the Platform is now a separate project. That means that changes to files in the "libraries/joomla" folder should be done as part of the Platform Project and not part of the version 1.7 changes to the CMS. It is possible, of course, that some 1.7 features will touch the Platform. If that happens, we'll have to evaluate and determine the best course of action.

Here is another important point. Our top priorities for version 1.7 are

  1. to have a high-quality release and
  2. to release it on time.

We want to have cool new features in 1.7, but exactly which features get in is less important than these two goals. In other words, if it comes down to a choice, we will choose to release on time and with the least possible bugs over adding a new feature. So, if you are working on something cool and it is not ready in time for the feature deadline, please remember that it is only a few short months until the next release. In that case, you are not late for this version, you are just a little early for the next one!

We are excited to see what the community comes up with for version 1.7. Happy coding!