OCL/Dev/Releng/ReleasesTransition

In this section we document the steps to be done in order to accomplish a successful transition between releases from the release engineer point of view.

Hudson jobs configuration

The first step in this process is setting up the new hudson jobs. To do so you should create hudson bugzilla describing how you want your jobs be renamed.

Once your jobs have been renamed it's time to configure them, because some job configurations are based on the own jobs names. To do so, you simply need to access to the jobs configuration page and look for occurrences of the old job name, and use the new one.

maintenance

The work required for maintenance hudson job is similar. The only additional bit that is required is that GIT branch from which the hudson job fetches OCL sources, needs to be accordingly changed. For instance, for Kepler-Luna transition, your should replace the maintenance/R4_0 text by maintenance/R4_1

Releng project configuration

In this section we explain the releng related files we will have to look at to accomplish our transition

Setting our new version

As a new release development stream starts a new version increment from the releng point of view needs to be taken. This release number is usually established by the project plann. From the releng point of view all the version usage has been factored out in a script which set some properties for the build. These files may be found at (org.eclipse.ocl.releng.buckminster/scripts) and they are the folllowing:

• ocl-core-pre-buckminster.sh
• ocl-tests-pre-buckminster.sh
• ocl-tools-pre-buckminster.sh

maintenance

The consideration must be done in the maintenance branch, in which we will increase the service release segment.

Adjusting RMAPS

We also need to adjust buckminster RMAPs file repositories from which our new release builds will be fed from. This point is a little bit tedious since we will have to connect to build eclipse servers to check that some of the projects we depend on have made their transition (that is, have created their P2 repositories for the new release development stream).

In order to configure our buckminster RMAPs, we may find two style of repositories definition which wee need to understand:

• those which explicitly specify a version for their different types of builds (for instance .../updates/4.2-I-builds). We will have to change the corresponding entry in our RMAP file, as soon as the project completes its transition and it starts to generate builds for the new release development stream.
• those which don't specify any version for their different types of builds (for instance .../updates/interim). We don't have to do anything since as soon as they start to run builds corresponding to the new release development stream, we will automatically be fed with them.

In order to accomplish the changes related to the first situation, we should login into build.eclipse.org and check if they have the expected repositories. Sometimes, this doesn't occur until M1 is getting close.

maintenance

Nothing is required to be done in the maintenance branch rmaps. They should already been configured from the main development stream to use the correct P2 repositories, which basically are the releases repositories in most of cases (we could find exceptions when a maintenance repository is provided by the projects we depend on).

Crontab file

The crontab file (org.eclipse.ocl.releng.buckminster/cron/crontab.txt) also needs to be updated since it contains paths related to the jobs location. Remember that, as explained by the README.TXT file (org.eclipse.ocl.releng.buckminster/cron/README.TXT), the crontab file only contains the entrances which need to be adjusted by the releng in his own crontab. Therefore remember to follow README.TXT instructions to also update the cron scheduling.

maintenance

The same changes should be applied to the crontab file, just in case we were working on the maintenance branch when we check this file.

API base line

As we start a new development stream, we need to set the new API base line. In the file(org.eclipse.ocl.releng.buckminster/APIBaseLine.target) simply adjust the location of the corresponding official release, and accordingly adjust the version of the features. For instance, the API base line for a Kepler release:

<unit id="org.eclipse.ocl.all.sdk.feature.group" version="4.1.0.v20130611-1511"/>
<unit id="org.eclipse.ocl.examples.feature.group" version="3.3.0.v20130611-1511"/>
<repository location="http://download.eclipse.org/releases/kepler"/>

maintenance

The same change is required in the maintenance branch.

Build servers configuration

Finally we need need to configure some infrastructure for our downlads area and P2 repositories.

• In the downloads area a new folder corresponding with the new version is created:

@build:~/downloads/modeling/mdt/ocl/downloads/drops> mkdir 4.2.0

• For every build type (nightly, interim and milestone) the corresponding composite repository require to be configured. For example, our Luna nightly repository may be created as follows

~/downloads/modeling/mdt/ocl/updates/nightly>mkdir 4.2.0
~/downloads/modeling/mdt/ocl/updates/nightly/4.2.0>cd 4.2.0
~/downloads/modeling/mdt/ocl/updates/nightly/4.2.0>mkdir core
~/downloads/modeling/mdt/ocl/updates/nightly/4.2.0>mkdir tools
~/downloads/modeling/mdt/ocl/updates/nightly/4.2.0> ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=core -Dcomposite.name="Eclipse OCL Luna Nightly Repository"
~/downloads/modeling/mdt/ocl/updates/nightly/4.2.0> ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=tools

As soon as the new composite repository has a valid content (produced by the corresponding build) we may configure the virtual one. For example, to configure our composite nightly repository:

~/downloads/modeling/mdt/ocl/updates/nightly>ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=4.2.0
~/downloads/modeling/mdt/ocl/updates/nightly>ant -f /shared/modeling/tools/promotion/manage-composite.xml remove -Dchild.repository=4.1.0

Some notes:

note: It's recommendable checking other composite repositories to provide consistent repository names
note: The composite releases repository doesn't need to be configure at this point. They are usually configured at 

maintenance

The same operation is required with our maintenance repository, taking into account that if we have just released the 4.1.0 version, we will have to use the 4.1.1 version number for the future SR1 release.

Other concerns

Remember that the aggregator configuration will also require new configuration:

• As soon as the aggregator simrel project aggregator project creates the branch corresponding to the old release and we have our first maintenance build in place, our "org.eclipse.simrel.build/mdt-ocl.b2aggr" file should be configured to use our maintenance build repository.
• A similar issue what respects the mdt-ocl.b3aggr file in master. Until we don't build our first milestone, we should configure that file to use an Eclipse OCL interim or nightly repository.