Changes between Initial Version and Version 1 of WikiStart/Admin/Releasing

06/19/13 15:32:19 (6 years ago)



  • WikiStart/Admin/Releasing

    v1 v1  
     1This page will describe the workflow about how to release 'next' to the new 'stable' flavor 
     3You need first: 
     5 * to get into a full, uptodate, bootstrap of the next branch 
     6 * to get the admin scripts checked out in this bootstrap: add base/admin_scripts in autoproj/manifest and run aup admin_scripts 
     8== First Step: Synchronize 'stable' and 'next' == 
     10It is possible that some commits in stable are not yet in next. To verify this, run: 
     13ROCK_FORCE_FLAVOR=stable autoproj status 
     16In the status messages, the 'remote' is stable and the 'local' is next. If remote has commits than 'stable' does not have, you should either: 
     18 - integrate them in 'next' by merging them: 
     19   {{{ 
     20   acd name/of/package 
     21   git pull autobuild stable 
     22   git push autobuild next 
     23   }}} 
     24 - ignore them completely (if, for instance, the changes are bugfixes that do not apply to the current state of 'next') 
     25   {{{ 
     26   acd name/of/package 
     27   git remote update 
     28   git merge -s ours autobuild/stable 
     29   git push autobuild next 
     30   }}} 
     32Do this until there are no commits in 'stable' that are not in 'next' 
     34== Second Step: push 'next' to 'stable' == 
     36The admin scripts contain the rock-release script that performs the 'push to stable' operations, namely: 
     38 - generate status pages (which will become the changelog entry for this release) 
     39 - tag the current state 
     40 - push it to next 
     42Run it with 
     48Note that this script is (mostly) idempotent: you can re-run it until it passes. 
     50== Third: update the rock package sets, commit the changelog == 
     52The rock-release script generates two documentation pages: 
     54 - stable-$ the status BEFORE the synchronization 
     55 - stable-$ the status AFTER the synchronization 
     57Where $date is a date tag for the date in which the release is being made. 
     59With the latter, you get the list of packages that are currently NOT on stable and should be put there. Modify autoproj/remote/rock*/*.autobuild to move the package definitions from the 'master', 'next' sections into the 'master', 'next', 'stable' sections. Commit but '''do not push yet'''. First run a complete build. 
     61With the former, you can create the changelog entry. It should be first modified to change the wording (e.g. "are in next but not in stable" becomes "new commits" and so on), compare [ the existing changelogs] with the generated pages to see what should be done there. Moreover, you have to add a title block. See files in the src/changelog subfolder of [ the Rock website repository] for example.  
     63Once the page is modified to fit the "changelog" wording, copy it into the src/changelog/stable-update-$ file [ in the Rock website repository], on all master, next and stable branches (add to stable and merge stable to next, next to master). Push all. 
     65Finally, '''start a bootstrap on the build server''' 
     67== Final: announce ! == 
     69Create an announcement message pointing to the changelog page (once the new bootstrap build on the build server is finished, the documentation/website should be generated and therefore the new changelog should appear). See former announcements for examples. The announcement is usually done on the blog as well as on the rock-dev and orocos-users mailing lists. 
     71If there are "highlights", i.e. really important new features, feel free to highlight them there.