Here we are again, following our bi-weekly releases plan with our third alpha release. We are still working hard to reach beta status as soon as possible and I would like to use this opportunity to explain what our criteria is and how our focus on high quality is driving this release more than ever.
Last week we had an opportunity to showcase the release at our North American Symposium in Chicago. If you couldn’t attend (or even if you could), keep an eye on the site since the slides will be published soon. Coming next we have events in Viena, Austria and Sao Paulo, Brazil (another great opportunity to meet many Liferay developers).
First I would like to highlight how Lexicon keeps evolving and all of the portlets that already use it get a better User Experience thanks to that. We are also applying lexicon-based designs to more and more out of the box applications. Specially those accessible from the product menu (that includes personal applications, site admin applications and control panel applications).
One portlet that fully finished its redesign is Site Teams. One view that I particularly like is the list of users within a team. It’s so nice that it’s worth showing a picture here:
Pretty neat, right? This is really how it looks, no photoshop at all.
The following applications were also fully finished:
Additionally some important applications debuted their new lexicon based design. The most relevant of them is Documents & Media and while it still has further work to do, it’s already looking and feeling so much better.
A new application also debuted in this release. It’s called System Settings and allows a super administrator to change the configuration at a system level from the Control Panel. System level configuration is the one that affects all portal instances and sites. The portlet offers many forms organized in 5 categories (subject to change) and is fully extensible. Any module deployed to Liferay 7 can use Liferay’s new Configuration API or OSGi’s Configuration Admin API to define their configuration and have an automatically generated form for free:
Alloy Editor, one of the most acclaimed products presented at our different events, has expanded its usage to several portlets.
In wiki Alloy Editor is used out of the box for both HTML and Creole formats. For Creole, check out the full page view and how you can use it to write Creole on one side and have a live preview next to it.
Pretty cool, right?
It has also been applied to the HTML fields of Web Content, Documents (metadata) and Dynamic Data Lists. For all of them Alloy Editor allows providing rich fields within the form without disrupting the desired flow for filling the form.
This is just the beginning though, we still need to do some look & feel tweaking to make sure Alloy Editor is perfectly integrated.
Finally, and I kept the best for last, the new Forms application has had many important improvements. Probably the most important is the ability to define a workflow for a form.
To make this capability even more powerful we have also made the default Workflow Engine, Kaleo, much more modular. Now the Action Executors are OSGi modules so it’s fairly easy to add custom ones to create any type of workflow you may need. This can be useful to integrate the with an external database or service.
Some other additional improvements of the Forms application are:
Ability to view details for an specific form entry
Added support for adding captcha challenges to forms
Ability to configure a redirect URL after submission
Ability to export the answers of a form to CVS and XML
That’s about it in terms of highlights. Check the full list of 58 improvements to find out more or just browse around since there are other “partially done” improvements that you won’t see in that list.
Release criteria for Alpha, Beta and Release Candidates
As promised at the beginning I wanted to cover a bit more than Alpha 3 this time around and explain our release criteria. Release criteria is the set of rules that we use to evaluate a release and determine whether we should flag it as Alpha, Beta or Release Candidate. For Liferay 7 we are raising the bar since a big goal for us this year is to have very high quality for 7.0 from the very first GA release.
In order to release Alphas, the criteria is:
All major features finished
60% pass rate for our automated priority 5 functional tests
Bundle with Tomcat available
This Alpha release met these three requirements (as did the previous two) and already met quite a few from the Beta criteria which are as follows:
Data upgrade finalized for all bundled applications: it’s almost ready but we missed a few fixes for web content and wanted to do some further testing with real world dbs to give you the go ahead to test it on your own.
Bundled plugins/modules included: our final bundles come with many plugins/modules included out of the box. For beta, we want them all to be included (in previous releases we skipped a few that were not fully ready)
Bundle with Tomcat and Wildfly available
Official languages translated to at least 70% of all keys
Releasability index: at least 75%. This is a metric that we came up with using a formula that takes into account all the known and verified bugs reported in JIRA (remember that your bug reports for alphas and betas help a lot) as well as pass rates for our functional automated tests.
We will keep making improvements to reach Beta status as soon as possible, but until then we will keep calling them Alpha
The next step after reaching Beta status is to get to Release Candidate (RC) status. As the name implies an RC release is considered to be a candidate to become a final release. Here is the key criteria that a release needs to meet as it is being built to be flagged as RC:
All Beta requirements are met
Releasability index: 100% (with 100% P5 tests pass rate and 0 Fix Priority 5 bugs fixed)
Environment tests running for all supported app servers and databases
End to end testing (including Marketplace installations and licensing)
Official languages translated to at least 99%
Lexicon based designed applied to all apps accessible through the product menu
Once an RC is out the door the final call will be made based on the internal and external testing performed after it comes out. If important issues are found after the release, they will be fixed and a new RC will be built until one is honored with the GA flag. Ready to be used in production :)
Ready to try it out?
Update Dec 1st: replaced the image showcasing Lexicon based improvements since the original one was of a view that didn't make it into Alpha 3.