Drupal 7 RC1 Released - Quick Report

Hi,

Yes, its a tough call and it also requires balancing on a pretty thin thread. On the other hand I believe the Drupal community is be able to do it.

As I see it, Drupal risk falling into the same trap as Internet Explorer. With that I mean that major new versions will be take longer and longer to release. Compare that to, especially, Google Chrome that is being released at a much higher speed. Google is pushing new internet advances because they see the benefits for the users. Microsoft, and to a certain degree Mozilla, is stuck in the old way of new major releases that has tons of changes, so many that it is hard to realise that the old version and the new version has a relation.

For the last years the introduction and adoption of new technologies on the Internet has accelerated. Google have understood this and adapted their release cycles to this. I am sure MicroSoft and Mozilla understand this too, but they haven't been able to adapt their development to the new situation.

For the future of Drupal Core this needs to be addressed. Drupal 7 is a fantastic improvement, but it is still behind, for example, WordPress when it comes to usability and easiness to get started with.

Can Drupal afford to wait another 3-4 years before Drupal 8 is ready or is it needed to change the release strategy to correlate with the current situation.

I believe the release strategy needs to change and I am already seeing discussions on drupal.org about this. The next few months is going to be interesting regarding this as I believe it will define the future.

/thomas

The decision to change the current release rules is not to take lightly as it will without a doubt introduce a lot of more work for the core maintainers, the security team and the developers.

For example, if a version system like x.y.z is introduced (X is major releases, Y means API change and/or new feature and Z is bug fixes and/or security fixes), then how long shall Y versions be supported and receive new Z updates?

Right now there are only two Drupal versions that are supported. The current major official release (Drupal 6.x) and the previous (Drupal 5.x). Those are the only ones that receive official bug and security updates. When Drupal 7 is officially released Drupal 5 is retired and will no longer be officially supported.

By introducing Y Drupal will tell people that if you want to have the new features it introduces you are welcome do upgrade to it, but there is a slight chance some modules/themes will not work correctly or break the site until they too are updated. That is fine since it is a clear indication.

However, it also mean there is yet another branch that needs to be supported and receive bug/security fixes. How long will each Y release then be officially supported? Until the life cycle of its major (X) release ends or should it only be the two last Y releases?

If its the whole life cycle it would without a doubt introduce a mountain of extra work. Imagine there is 6.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, then all of a sudden you have five official versions that all have to receive bug and security fixes. Then when Drupal 8 is released its going to be even more as all the 7.Y.z still has to be maintained.

The extra work is also not linear, its exponential since fixes to 7.3.x often has to be back ported, and tested, to all previous 7.Y.x versions.

Drupal is open source and work is done on a voluntary basis. Finding anyone who would gladly put up their hand saying they would love to take responsible for the above will be as hard as for that person to actually perform the task.

This will also affect module developers since they too need to adapt to they new system and might end up having to maintain several official versions for the same Drupal major release.

OK, that was a worst case scenario, but I think you get the idea that this is something that can't be taken lightly. If it is done wrong it can easily turn into something that is much worse and will prevent Drupal from progressing and become better.

As I mentioned earlier, this is something that has started to be discussed on d.o. A lot more discussion is needed to come up with a schema that will not introduce the situation I have described above, while still make it possible to introduce changes in a controlled manner.

/thomas

Updating Drupal core is a very different thing compared to updating modules. Especially considering that you will be updating the code that is used to perform the update itself.

There are also at least two files, .htaccess and robots.txt, that needs special care if they have been changed by the user.

The update manager is a big improvement and addition in Drupal 7. It might seem like an easy task to update a module; Detect modules that has newer versions, download them, put the site in maintenance mode, install the new version, run update.php...

In reality it isn't. There is a whole flurry of new challenges going from a manual process to a fully automated process. Check out this list over at drupal.org that lists some of the problems still remaining for it.

I'm sure that updating Drupal Core will come at some point in the future. For me at least being able to updating modules quick and easy is more important since you have to do that all the time compared to core.

Yes, WordPress has support for this, but they have offered that for years and have been able to polish and tune it to work really well. This is a major new feature in Drupal and it needs to be done right. Thus starting with modules and themes is a good balanced decission.

/thomas