Jump to: navigation, search

OpenstackChefStablebranchCreateNotes

Revision as of 21:42, 26 February 2015 by Kramvan (talk | contribs)

Steps to create stable/<release> branch

Awesome! We've decided as a group to create the next stable branch. Here are some steps to remind you on how to do it.

  1. Go to for each repo as a core member and create the branch with the SHA you want.
  2. To get Gerrit to report to the #openstack-chef channel create the "stable/<release_name>" via openstack-infra/project-config project under: gerritbot/channels.yaml. Something like this is an example. You may be required to remove an old branch too, keep this in mind.
  3. Wait for the Patch to be merged by Infra
  4. Changes for each cookbook and repo
  5. Create a bug to tie all the following branch work togehter
    1. update .gitignore to remove both lock files
    2. update.gitreview to ref defaultbranch=stable/juno
    3. update Berksfile to ref branch: 'stable/juno'
    4. create Gemfile.lock then Berks.lock
    5. see https://github.com/stackforge/cookbook-openstack-identity/commit/3a99613b89fb28d21def8cbeaa63e40da32768f5 for example
  6. Create a review with the above and put it up against the stable/<release> branch.
  7. Get it merged in and you should be good

Steps for new master branch

Now we have a new master, need to get it in sync with matching base openstack release.

  1. Possible infra changes for changes to the gates we want for this release
  2. Decide on new levels of tools (rubocop, foodcritic), we have always be trying to move forward with these
  3. Changes for each cookbook and repo
    1. once infra gate changes are in place to handle it, update Gemfile wtih new levels
    2. create robocop TODO file to outline that work to be done
    3. update.gitreview to ref defaultbranch=stable/kilo
    4. update code with refs to old openstack release juno -> kilo (defaults, readme, ...)
    5. update each conf file with any new base openstack defaults and new/changed sections
    6. update all code looking for deprecation's that can now be removed
    7. update and package dependencies that have changed for each component
    8. in this juno to kilo case, we decided to remove all Changelogs and rely on git log
    9. update all spec test platforms to targeted levels we want for this release