Best practices to maintain different Worklight Studio patch versions

Question

Whenever there is a new update of the worklight studio available in the eclipse market place I install it to get the latest fixes. When I restart eclipse after installing an update, Worklight triggers some kind of process to update my project to the new version. During this process worklight does some black voodoo and updates some files.

I suppose that once I commit these files, the entire team should download and install the new update from the eclipse market place? Because it can't be a good idea to work with an old version of Worklight Studio on a project that was already updated to work with a newer version.

Are there any best practices on this topic?

Is it a good idea to update your worklight studio on a regular base? I'm not talking about minor or major versions, just a new patch which is available in the eclipse marketplace. Take for example an update from platformVersion="6.2.0.00.20140701-1500" to platformVersion="6.2.0.00.20140724-2139"

If you choose to stick with one specific version, how do you distribute this to new members in your development team? Should you keep a copy somewhere? And what happends then if you need a fix?

Stacte

Answer 1

I suppose that once I commit these files, the entire team should download and install the new update from the eclipse market place? Because it can't be a good idea to work with an old version of Worklight Studio on a project that was already updated to work with a newer version.

If you do not work alone, and you upgrade your Worklight Studio version (which then does "black voodoo" and updates the project's files) and you then deliver your changes to your SCM, then yes - your team members must upgrade their Worklight Studio plug-in as well.

Are there any best practices on this topic?

As a Worklight development team member, my advise is: if we publish a fix to Eclipse Marketplace / IBM Fix Central - yes, install it.

That said, you can also review the list of fixed bugs ("APARs") in IBM Fix Central and decide whether you'd like to upgrade your installation.

Before doing so, you can opt to first install this fix in a new Eclipse and workspace and make sure your project is not getting broken. If you feel all is OK, upgrade your main development environment and instruct your team members to do the same, then, migrate the project using the new Worklight Studio version and deliver your changes to the SCM.

If you choose to stick with one specific version, how do you distribute this to new members in your development team? Should you keep a copy somewhere? And what happends then if you need a fix?

Branch your code in the SCM based on the version? But why create headache...

Twoedged

And when a new team member joins, how do you make sure he installs the correct version? Because when he installs eclipse and downloads Worklight Studio, his version won't match with the rest of a team. Should you zip your eclipse and version it somewhere? – Stacte

That's also a possibility indeed. When you feel confident enough in your development environment you can simply create a stand-alone zip of your Eclipse already installed with Worklight Studio and ADT (if used). I do this as well. – Twoedged

@Hans, Also keep in mind that Eclipse Marketplace contains the Developer Edition of Worklight Studio. It is a free offering for evaluation purposes so only the latest version is ever available there. Once you purchase Worklight (Consumer or Enterprise edition) you will have access to all of the ifixes and fixpack levels on FixCentral. – Puppetry