We want the best release process possible

Determining the best strategy for doing releases is one of the hardest challenges of developing a software product. We get lot's of feedback related to it, although it's usually in the form of indirect comments or questions. Some very common examples are:


   "When are you going to release the next version? I really need feature X"

   "Another release? I just finished migrating to the previous one"

   "Is it safe to upgrade to release x.x.x?"

   "Is the release x.x.x production ready?"

   "This release should have been named y.y instead of x.x"

   "Don't use version x.x.0 in production. Wait for x.x.1 or x.x.2"

We pay a lot of attention to this type of comments because they guide us to choose the best possible strategy for our releases. The basic compromises are:

  • Delivering new functionality as soon as possible
  • Keeping releases very stable and backport fixes to them for as long as possible

In the 4.3.x set of releases we tried a new approach to make new features available faster. Every feature that was added to the product and had initially been planned for 4.4 was reviewed and if it didn't seem to cause migration issues, it was added also to the 4.3.x line. That way each of the versions from 4.3.0 to 4.3.5 has, not only bug fixes but also some of the new features. This is the same model that the Linux kernel used until recently or the Gnome project still uses, although with a different version scheme. This way of doing releases has the huge benefit of rolling new features out very fast. But we've also found that it has drawbacks for people looking for a very stable platform but also want bugs fixed.

The reason why I'm blogging about this is because we just had a meeting yesterday to talk about all of these ideas to improve Liferay's release process. Mike has already blogged about our conclusions. The most important is that we will be going back to the traditional way of doing micro-releases that only contain bug fixes and no new functionality at all. But at the same time we want people to be able to use the newest functionalities as fast as possible, how can we do that? We've decided that we are going to try to make frequent and periodic releases with a known and predictable release cycles. This is the same idea that is working very well for Ubuntu. We don't know for sure which period will be the best. We'll start with two months but may adjust later based on your feedback.

In order to be able to release so often, we will probably need some help from the community. Specially for testing. We are already contacting the most active and trusted community members to start a beta testing program. We'll ask them to test a new version of Liferay in their environment and will give them full attention during the period of time prior to releasing to fix very quickly any issue that they may find. We've just started, but we already have the first committed beta testers (thanks a lot guys!). We'll add a list of all the beta testers to the site so that they can get the respect that they deserve. We also want them to benefit from being part of the beta testing program by getting our help to make sure that the new version will work well for their environment.

There are some other details of the improved release strategy, including creating Long Term Releases (LTS). Those are releases that will be supported longer and fixes will be backported to it for a longer period. So if you want the greatest stability possible and don't care about waiting a little bit more for the newest functionality you should always pick an LTS release (4.4 will be one of those). Also we'll create a wiki page at the beginning of each release cycle with the planned features for the next release. Liferay Portal is known to be very fast at incorporating new technologies and features and we don't want to loose that, so we will still add features even if they were not originally planned. What we want to do is to have a list of what we absolutely want to have in the next release, so it'll get higher priority than anything else. Any other feature may get in if it doesn't delay the date or cause any of the high priority ones to be dropped.

I think I've covered all the important decisions we made. Now it's your turn to give your opinion and let us know what you think.

Blogs
Hey, that sounds like a very good strategy. I am very much interested in the beta testing program. We have deployed liferay in our company intranet and i'm responsible for its development and maintenance. We started with version 4.2.1 and i'm currently working on the migration strategy to 4.3.5.
Although I'm burried in work, I'm very interested in the beta program too... The main reason is that we have developed a highly customized liferay based app, and for one reason or the other, i always need feature X from the next release, but hessitate to migrate due to new bugs added to releases...

Having a LTS sounds like a great idea.

Currently the main issues i have are related to clustering effectivly... You ask about what we want to see: Well, clustering that integrates effectively all available parts of liferay (db cache, search, document repo) ... The traditional clustering model, and now that it may be possible, Terracotta sounds very interesting.

Thanks a lot for the hardwork!
Hi Darshak, Alex,

Thanks a lot for your interest. We've already started the beta testing for 4.4 but we'll soon need more help to beta test 5.0.

Also feel free to checkout the 4.4.x branch from SVN and test it, even if you guys are not yet officially in the Advisory Board.