Moving to a new release

This page is part of the daily release process documentation

What are we going to do when we start branching upstream for an older release as they want to develop new features on trunk?

100 feet view

The goal is to have in the end both "trunk", pointing the new features branches, and a maintenance series branch for the actively maintained series (like raring here). Head is pointing "trunk" and raring the 13.04/raring branches. For that, we will go through increasing steps over time:

• create the "raring" series in our daily release, landing everything as we did for head. We then disable all head projects and prepare to land in the next ppa. The only difference is that all projects will now land throught the raring jobs instead of head. This is totally transparent for upstream.

• we then change one after another all the jobs in both release for one stack:
  • add a parameter to tell what branch should be used now on that project for the maintenance release stack.

  • reenable trunk landing for that project in the head release stack.

• Once the new release finally opens, we need for all stacks in head to disable landing in a ppa and bump the series to the real destination.

Step one: release+1 is not opened yet

Example: s<…> is not opened yet, so we need to build raring and branches for s on raring. Only the real "raring" branches should land to distro.

Do a batch change (one time)

We do ensure that we have a raring series along head like here. "head" will become then s<…> for all stacks as soon the branches will be moved to the new repository.

Copying head to the maintenance release

In the stack configuration:

• copy the head/ content to a new <release> one (like raring/). Do not forget to bzr add

The result can be seen here.

• then, add maintenance-version: 'xx.xx' where xx.xx is the version of the maintenance distro. This will be appended to the version at the end of the version string. More info on why here. Please note that that the ' around the xx.xx string is mandatory (otherwise, 13.10 will be converted as a number for instance and will be 13.1)

The result can be seen here.

Disabling head jobs

• then add to_transition (or any other string) between the "projects:" stenza and the projects themselves in all "head" stacks. This will make the stack not having any "active projects".

The result can be seen here.

Preparing the ppa configuration and setting the new series version

So, until release+1 is opened, we need to land the new features in trunk in a ppa. We can't use the same daily-build ppa because we would build both "raring" and "head" here on the "raring" series until s is opened. Let's do the needed changes for that.

We are using the daily-build-next ppa (equivalent for daily-build ppa used for daily releases to distro) and the next ppa, equivalent to the distro. We need first to target the right ppas.

• The ppa parameter should be set to daily-build-next instead of daily-build and dest should be added (otherwise, it would be "distro") to target the next ppa. (finale destination). You can see the relevant diff.

• At the same time, we change series-version in all head stacks to match the next release (like '13.04' -> '13.10' for instance)

• Verify that the names of the autopilot nodes match the value of the entry apmachines in the configuration files of the stacks.

Copying autopilot results from head to raring

• On the jenkins master, you'll have to copy the archive of autopilot jUnit results to keep the history.

• History is kept in ~jenkins/cu2d/history . In this directory copy head to raring then, edit the files *.autopilotrc in raring and change the value of the parameter history to point to the new location i.e change head by raring.

Deploying those changes

• redeploy all stacks one by one on both "raring" and "head".

-> you will still see the project jenkins jobs for the "head" release of jenkins. Do not fear that, they are not removed, but just "disconnected" from head.

Creating the new "raring" view

• The structure of the Jenkins view for CU2D is cu2d/RELEASE/STACK:

- cu2d
    - All
    - experimental
       - 100scopes
    - head
       - friends
       - indicators
       - oif
       - ...
    - raring
       - friends
       - indicators
       - oif
       - ...

    - ...

• The Master view cu2d is a nested view

• The RELEASE view is a nested view

• All is a list view and lists jobs matching the regular expression cu2d.*RELEASE$ where RELEASE is the name of the release e.g raring or head

• Stacks views (friends, indicators, unity, ...) are dashboard views. They list jobs matching the regular expression cu2d-STACK-RELEASE.* where RELEASE is the name of the release (e.g raring or head) and STACK is the name of the stack (e.g friends, indicators, unity, ...)

  • The top of the page displays the portlet Unstable Jobs

  • The bottom of the page displays the portlet Jenkins Job List

• You must create the releases and stacks matching the configurations files in cupstream2distro-config/stacks/

• File an RT against the queue ubuntu-qa to have the view configured on the public jenkins instance jenkins.qa.u.c

Diverging "trunk" and a "maintenance" branch

This of course applies only once upstream wants to separate their branches between "trunk" and "maintenance" (so as soon as you have one target_branch in your stack). Remember that we disabled all projects in all stacks in the head release as part of the batch change (first paragraph).

The changes needs to be applied in both the "maintenance" release and "head" to have the new maintenance branch daily releasing to distro and trunk landing as part of head in the next ppa.

New branch for the project

Upstream needs to setup a new maintenance branch for the project. It will be useful to check that they change the Vcs-Bzr property in debian/control as well to point to the new maintenance branch.

Changes in the maintenance release stack configuration

Here is an example of moving the indicators stack from head to its own "raring".

What we can notice is:

• raring/unity.cfg is now having some target_branch properties to target a particular branch. This is the maintenance branch naming that you have to agree with upstream. lp:<project>/raring (13.04 or raring should be used for the new upstream branch serie for clarity). So talk to your upstream who wants to create those branches to have trunk on a feature-mode and then one maintenance branch for that release.

• Please do note that some doesn't have and are still targetting trunk (there is no target_branch property): That means that upstream doesn't want yet to work on new features and prefer just having one branch (they didn't diverge).

Changes in the "head" stack configuration

• For each projects where upstream have an independant raring and trunk branch (so, for those having a target_branch parameters in the corresponding "raring" release stack), we move trunk target back to the projects list. This can be seen there.

• Please note in the previous example that we still have some projects under the to_transition stenza, as trunk is still used directly for pushing code to raring (the branches didn't diverged). Take great care to have that part right, as we really don't want to have daily release conflicting (we can write a tool in the future to check that before deploying). The only side-effect I can see is a bad merge back feature. But let's avoid it

• Ensure (or do a MP and ensure it's merged) that the version in this diverged branch is bumped to a new version that will always be "higher" than the one in the release-1. This is needed when we open the new release, the new version should be higher.
• Change head 'extracheck:' parameter to the new release for all the head stacks

Ensure upstream merger is setup on the new branches

Ping the QA team for upstream merger to ensure they deploy the change you have just done in cupstream2distro-config in both head and raring for your stack.

Deploy both stacks you modified

Finally, as always when you change anything in a stack, think about redeploying the stack you just modified.

Final Freeze of a release

Note that's a good time to finish diverging the old and new stack if you didn't yet. Please keep upstream posted and ensure they are on board with those.

For any stacks in the new maintenance release, add manualpublish: True as shown here and connect to desktop-team@<jenkins-machine>. Then cd cupstream2distro-config && bzr pull.

FIXME: this should rather be: redeploy the stack you just modified in the future (but not yet)

From now on, the stacks in the release maintenance will be daily pushed and tested from the ppa. So we'll get the health everyday of the maintenance branches. However, the publication will be manual, on your responsability, to distro.

Step two: once release+1 is opened

First setup on the jenkins server

• we need to create a release+1 pbuilder. Ping jibel for it.

Then, for each stack

• Ensure the schedule is on for the head stack and that there is nothing more under to_transition

• Change in the configuration file:
  • the series should be release+1 name
  • remove the dest line
  • set the ppa to ubuntu-unity/daily-build instead of daily-build-next

• Redeploy the stack you just modified.

Here is a simple example.

Also, you need to ensure that trunk is synced with latest packages in release (as they are copied over automatically from release to release+1 at the start of the stack). You will see otherwise the prepare job being yellow, showing that some components are not up to date. For that, you mostly have to:

1. branch trunk
2. branch release-1
3. merge release-1 to trunk
4. add an entry changelog (manual bootstrap commit) telling which revision was the divergence from, to ensure we don't miss any commit. Indeed, the latest message revision from the merge from release-1 to trunk may not exist.