Changes in Liferay's front end

If you follow our trunk as ardently as I do (and really, who doesn't) you might have seen some front end changes, and there might have been some theme changes that are a little different from what you were expecting.

There are some big happenings going on in the front end of Liferay, and I'll have some more details for you shortly, but I just made a commit that I wanted to talk about that I think will make developers quite happy.

I added a file called deprecated.js to portal.properties. This file is a place where we will deprecate our changing Javascript so that that the upgrade path between major versions is a lot smoother.
This file will be updated any time something from the Javascript API has been changed from the previous version.

Here's how it will work:

As soon as a piece of script is changed from a previous version, such as a variable being removed, certain options changing, etc, we will place code inside of deprecated.js that will make the Javascript work for the next version.

So let's go through an example. One thing we've been wanting to do is clean up the amount of room we take in the global namespace. We have a few outstanding global variables, such as LayoutConfiguration, or themeDisplay and we want to clean those up to protect from future namespace collisions.

So assuming we move LayoutConfiguration to be accessed from Liferay.LayoutConfiguration, we would add code inside of deprecated.js that will keep the backwards compatibility for 1 major version.

So in 5.3, the deprecated.js might look like this:

//To be removed in 5.4

// LPS-1234
LayoutConfiguration = Liferay.LayoutConfiguration;

// LPS-4567
themeDisplay = Liferay.ThemeDisplay;

 

However, in Liferay 5.4, this entire block would be commented out.
It will still be in the file, but it will be commented out. The reason behind this is so that developers who are running behind in upgrading between versions can still uncomment their code and have things work for the most part. It's kind of our way of letting you know what we recently removed.

In Liferay 5.5, this block would be removed completely.

So in any version from 5.3 on, you would be able to see what is scheduled to be removed and what, if anything, was removed in the previous version.

There are a couple of reasons for this change, and I wanted to talk about them.

One of the areas where I believe Liferay shines is in innovation. We are able to rapidly change faster than any organization I've worked for. However, whenever things change rapidly, not everyone is able to keep up. It's very easy as a developer to forget this, unless you're the developer who is trying to keep up :)

One of the reasons we introduced Liferay Enterprise Edition was because people, especially enterprises, need a stable and robust way to get bug fixes, security patches and performance enhancements, without having to upgrade an entire revision number.

In that same vein, we're adding the deprecated.js, not just as a service to EE customers, but as part of the general process.
So we have spent some time now trying to come up with creative ways to allow innovation, while making sure that we make upgrades a lot smoother.
I'm not trying to portray this as the end goal in and of itself, but more or less a piece of the process and a goal we're striving for.

We still have a lot of areas where we can improve, but this is more or less to let you know we are, and the steps we're taking in getting there.

What are some other ideas? Bryan Cheung and I were talking earlier today about communicating to folks that don't have the time or mental bandwidth to scour through commit logs and LPS tickets. What we were wondering is, similar to Liferay's twitter feed what if we had a Liferay Developer twitter account? Is that something anyone would be interested in?
Basically, it would contain short snippets and bursts on stuff we're working so you can keep a loose idea of the happenings going on with the development team.

For instance, if I add some awesome functionality to the JS, but it doesn't warrant an entire blog post, I could tweet something like "Added the ability to create ajaxable panels: LPS-12345" which would have a link to the ticket where I discuss what was added.

Would this be helpful to anyone?

Also, in the lead up to Liferay 5.3, there will be some very big UI changes coming, and I will blog in more detail about that, but the other plan is that as everything progresses, I will be blogging about the individual changes and milestones.

Another option that has completely changed my life and sanity is that Mike Young recently installed Fisheye to watch our commits. I think the feature I have most used is the RSS functionality. I subscribe to commits by directory and also by committer. For instance, I am usually interested in a couple of commits. Anything committed by my friends Eduardo Lundgren or Peter Shin, anything committed to the portal-web directory and anything committed to the themes or to the js directories (I know there is some duplication there, but I'd rather have a bit more info).

If you want to stay on top of what people are doing, it's an awesome way to keep your ear to the ground.

So there are some ideas. I would love to have feedback, especially on ways to better communicate with you guys that extends beyond our normal routes.

Blogs
The deprecation idea is very good, congratulations for that, Nate!

I really like the concept of the Liferay Developer twitter account, it would be very nice to see all the changes in small sentences.
Instead of twitter, you could staat using the irc channel available quite some time... maybe we need to promte that instead of adding another communication channel... #liferay at irc.freenode.com