||<>|| = Moving to a new release = This page is part of the [[DailyRelease|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''' [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/files/110/stacks/|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 [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/files/head:/stacks/|stack configuration]]: * copy the head/ content to a new one (like raring/). Do not forget to bzr add ;) The result can be [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/110|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 [[https://wiki.ubuntu.com/DailyRelease/FAQ#modification_for_maintenance_branch|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 [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/193|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 [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/111|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 [[https://launchpad.net/~ubuntu-unity/+archive/daily-build-next|daily-build-next ppa]] (equivalent for daily-build ppa used for daily releases to distro) and the [[https://launchpad.net/~ubuntu-unity/+archive/next|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 [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/114|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 ==== * [[https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack|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 ==== [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/164|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:/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 [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/164|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 [[https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack|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 [[http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/207|here]] and connect to desktop-team@. Then cd cupstream2distro-config && bzr pull. FIXME: this should rather be: [[https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack|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 * [[https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack|Redeploy the stack you just modified]]. Here is a [[https://code.launchpad.net/~robru/cupstream2distro-config/friends-saucy/+merge/162712|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 1. branch release-1 1. merge release-1 to trunk 1. 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.