Someone else has commented on the confusing nomenclature. I agree. the history of versions in SF files shows a sprinkling of RC1 and RC2 releases. The oddest sequence is 5.0.0 RC, 5.0.1 RC, 5.1.0. The 6 series goes 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6. Then it goes haywire. 6.1.0 B3, 6.1.0 B4, 6.1.0 RC1, 6.1.0 GA1, 6.1.1 GA2.

Unless you are following discussions like this (which I have just read), how do you make sense of this? I assumed that GA was a new designation for a general release.

When you look for the plugins, 6.1.1 GA2 is nowhere to be found. The corresponding plugins are apparently still 6.0.1 GA1.

When I go to upgrade, I look for the instructions, some details of which I recall from an earlier, unsuccessful, attempt to upgrade. But the former detailed instructions have disappeared, replaced by a couple of cursor wiki pages without details. The new, improved, User Manual integrates all of that. Except that it doesn't. As far a I can tell, there is no mention of upgrading in the new document. It is supposed to be a work in progress. The GA2 downloads include a db-upgrade, which is basically a pile of jars, a build.xml for use with Windows, and a run.sh script for *n*x. Must I run this first? Will the new format media library library be updated from my data directory when I first run, after executing the db-upgrade process? Who knows?

What all this adds up to is a picture of a development and release process that has spun out of control. AT the very time that Liferay is picking up greatly increased numbers of enterprise - i.e. paying - customers, the release process falls apart. Maybe management is shell-shocked by the influx of very noisy, very demanding, paying customers. At precisely the time Liferay needs to demonstrate its maturity and stability to consolidate its new customer base, the wheels fall off.

Everyone here wants to see LR gets its act together, because we all have a considerable investment in LR's success, whether we are paying customers or not. At the moment, though, there is no sign that the problem has even been recognised.

Hey Peter, check out Jorge's blog post and corresponding wiki page for a description (I think this belongs in the official docs as well). Keep in mind the new nomenclature took effect starting with 6.0, and explains what Bx (Beta), RCx (Release Candidate) and GAx (General Availability) means. These are standard terms used in software development and release processes throughout the industry. We have been using it consistently for the last 2 years.



The nomenclature described above applies to Liferay Portal, not the plugins. Plugins are designed to work against a specific release, and up until GA1, they were placed on sourceforge in a directory corresponding to the release of Liferay they were built against (such as 6.1.0 GA1). Plugins are now released on Liferay Marketplace instead of SourceForge, but using the same nomenclature to describe which Liferay Portal build they are designed for. So the nomenclature remains consistent and still in effect (also, I think you mean 6.1.0 GA1 - this was the release back in January).



The new, improved User Guide includes detailed and official documentation on upgrade.



EDIT: The nomenclature has been successfully used for the last 2 years. I do not recall a discussion about its nature (confusing or otherwise). Can you point me at it?

As stated previously, we are working hard to improve our predictability of releases. GA2 was an aberration, and it was due to a number of interdependencies between it, Social Office, and Marketplace. So I would disagree with your characterization above, but I do understand the need for predictability and we are indeed working on improving that, through more frequent CE releases and better handling of community contributions.

Doesn't this underline the point about confusing nomenclature? (Yes, I did mean 6.1.0 GA1.)

It also says something about documentation in its broadest sense. But locating the information you need about particular questions has always been problematical.



A search on the contents page for 'upgrad' yields only the property. There is no index. In previous versions, IIRC, upgrading was noted in the contents. And why wouldn't it be?



See the comment by Stephan Schoenberger. That, btw, is a very sensible post in general.



When I talked about being out of control, I was talking about this release; that is, the current situation. It shouldn't have happened, because problems are going to happen when you throw too many major changes into the mix. This is, in spite of its numbering, a major release. Yet it is called 6.1.

Everyone here, including me, is urging LR to success. But if you don't recognise that this release has been a shambles, how are you going determine the causes and prevent its happening again?

I don't have too much confusion with the nomenclature but some with how the release are handled. I thought it was going to be Beta and RC before each GA where community members can test. Unfortunately, this wasn't with GA2 maybe because it was only suppose to be a simple bug fix version?

Yeah I can see where that might be confusing. Betas occur before each GA1 release. If there are issues in GA1, then those are fixed in a GA2 (with GA1 serving as a beta of sorts for GA2). Of course, that's only when necessary (and yes, it's been necessary in 6.0 and 6.1 ). But theoretically there should only be one GA per release family, if testing is adequate and functionality is enough. But that rarely happens as you know GA2 through GAXXXXX is supposed to be bugfixes only, no incompatibilities, etc. We are getting better at enforcing this rule through our testing mechanisms, and Marketplace will also be a good forcing function here.

We have chosen to use a x.y.z versioning scheme for the underlying version. So 6.0.1 and 6.1.0 are not the same, and 6.1.0 is "later" (and can be assumed to be "better") than 6.0.1. For each version, we tack on a human-readable name (like GA1, B2, RC3, etc). There are other options (for example, we could drop all of the x.y.z and GAs and betas and just stick to an integer, e.g. Liferay 6, 7, 8, etc). There are many ways to do this, and I'd be interested in any suggestions on how to improve on what we have.



When I search, the "Maintenance" chapter is the 3rd hit. Here's a suggestion - in the property docs, for each one, we provide a pointer into the official docs which talks about that particular area (if there is indeed an area that matches). That way, someone reading portal.properties could quickly find the place in the official docs talking about that functional area.



I went back and read it. It's not really talking about nomenclature, but Stephan is talking about the release timelines and quality in general, and one his concerns was that he doesn't feel that Liferay 6.1 GA1 was more stable than 6.0.x. At the time of any GA1 release, we feel that it *is* production quality, or else we would not release it as a GA. So it means that we need to do more testing on our GAs (btw, we did do 4 beta releases of 6.1, and many of the community contributed fixes in BugSquad and other areas), but we can do better. I'd like to see our nightly test results published, and have an easy way for the community to contribute to these test beds. Right now, it's confusing and not well documented for the community on how one can contribute in this area, other than manually testing and filing bugs.



Totally agree, we don't have enough checks and balances in place to determine whether a release really is "major" (according to Jorge's guidelines in his blog post). 6.1 did include several new features (which is allowed in a minor release, according to our definition of minor), and APIs were not properly deprecated (which should not have happened). One of the things we're doing with Marketplace is that we're going to use the apps themselves as an additional check - if there is a really popular app in there, the developers of that app will get mad if we break their app in a minor/patch release. So in effect we'll get free test cases for future releases. Also, doing 6.1 GA2, Marketplace, and Social Office on the same day was in retrospect very difficult and resulted in many delays. But it's over now, and we've learned a lot, and we are continually trying to improve.



I appreciate your honest feedback, and you can rest assured that others in the company and community do as well. We are addressing the following issues:

- Documentation - See the updated documentation, we have gotten a lot of positive feedback (see Rich's blog and comments, and I know you already saw this, but this is for others ). Documentation has come a long way in the last 2 years thanks to Rich and the community, so I urge you to get involved in the process if you can.

- Release quality - Always at the top of the list in terms of priority, but we need to and can get better. Liferay is a large open source project, and it's difficult to keep tabs on every nook and cranny, but internally we have made a lot of improvements this year during the GA2 release development time, and will result in higher quality going forward. But I still want to make it easier for the community to contribute here (e.g. have better developer docs for contributing to tests, nightly test results, etc). Also, education in my opinion is very important and we don't do a lot of community education outreach programs, but we're working on some in the CST as I type.

- Release timelines - We are going to do more frequent releases going forward for CE - more GA's on a regular schedule vs. "when the time is right", and provide better status via a status dashboard (see below).

- Security - See the newly-formed CST.

- Contributions - Drew Blessing is forming a new effort in the Community Verifier program - the goal is to deal with contributions in a more timely fashion, and get our external community more involved in the development process, by getting to know the development process better, getting to know the core engineers in the project, and ensuring that new contributions are baked into the project faster and with higher quality. Hopefully, once that program gets underway (and finishes), we'll learn a lot about how to improve our contribution process. This is a top goal of mine this year, and all contributions should be treated as a gift from the community and not ignored.

- Communication - this falls on my shoulders. I'm working on a new releases dashboard showing all current and previous releases, including those under development, their expected ship dates, and reasons for delay (if any). Besides that, we communicate across a bunch of different channels, hopefully with some consistency - forums, blogs, IRC, social media, etc. I'm thinking about instituting a regular (e.g. every 2 week) meeting on IRC so we can have better communication more frequently. I agree (from Stephan's post) that just putting something buried in a forum isn't enough.

If you have any other suggestions on how to improve, please let me know.

So if it's not too impertinent to ask, should a portlet developed for 6.0.x work on 6.1GA1 without modification? Should a portlet developed for 6.1GA1 work without modification on 6.1GA2?

Bob

Any opinions expressed are my own.

Plugins developed for 6.0 may not work without modification on 6.1 but plugins developed for 6.1.0 should work without modification on 6.1.1.
Unfortunately, liferay.com's revisions don't always follow this because there's sometime data column modifications.

Yeah, Hitoshi is right - that's the way it's supposed to work. Unfortunately we've not always followed that but I think we are making progress toward reaching that goal in the next couple of releases.