Changes between Version 15 and Version 16 of WikiStart/OngoingWork/RockFlavorsOrReleases


Ignore:
Timestamp:
01/05/15 21:23:06 (5 years ago)
Author:
sylvain.joyeux
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart/OngoingWork/RockFlavorsOrReleases

    v15 v16  
    22 * [[./WhatDoWeWant]] 
    33 * [[./How|The technical means and process for releases]] 
     4 
     5= Autoproj's log, tag, commit and reset = 
     6 
     7Autoproj is gaining the general ability to save the state of the source code of a complete autoproj installation. The key features are: 
     8 - the processing of overrides information stored in multiple files in autoproj/overrides.d 
     9 - the ability to pin package sets 
     10 
     11From there, the following things are implemented - '''ASSUMING THAT THE MAIN AUTOPROJ CONFIGURATION ($AUTOPROJ_CURRENT_ROOT/autoproj/) IS UNDER GIT'''. In all the following items, autoproj/ is this repository. 
     12 - autoproj auto-logging. Each time autoproj update is executed, autoproj: 
     13   - takes the current HEAD of autoproj/ 
     14   - adds the current state of the system in autoproj/overrides.d/50-versions.yml 
     15   - saves the result as a reflog in the autoproj/ repository '''without modifying anything else (no modification to branches / tags and working copy). The log can be displayed by running autoproj log, or directly with git by running git reflog autoproj. As a reflog, it is automatically pruned by git after a certain amount of time (the default timeout is 30 days I believe) 
     16 - autoproj tag 
     17   - takes the current HEAD of autoproj/ 
     18   - adds the current state of the system in autoproj/overrides.d/50-versions.yml 
     19   - saves the result as a (git) tag in the autoproj/ repository '''without changing either the working copy or the branches'''. This allows to save permanently, and optionally publish, an interesting state without interfering with the work of the developer. 
     20 - autoproj commit 
     21   - explicitely saves the state of the system in autoproj/overrides.d/50-versions.yml, in the current working copy 
     22   - commits the result on top of the current branch 
     23 
     24 - autoproj reset 
     25   - takes as argument a commit ID: 
     26     - reflog name as e.g. autoproj@{2} obtained from autoproj log 
     27     - tag name 
     28     - branch name 
     29   - gets the 50-versions.yml file from it 
     30   - resets all repositories to the state described in this overrides file 
     31   - if --freeze is given, leaves the versions file in the working copy, otherwise leaves the autoproj/ directory unchanged. 
     32 
     33 
     34= Workflows = 
     35 
     36== The updates-always-break-something situation == 
     37 
     38The first situation that snapshot aims at fixing is the uncertainty related to running autoproj update. Updating can break the current system (even when working with a Rock release, we all are using the master of a bunch of packages that either come from our private projects or because we develop them within Rock). 
     39 
     40The developer should be able to go back to the previous state of its Rock-based project after running updates when he realizes that something is broken. 
     41 
     42autoproj auto-logging provides the logging, autoproj reset [--freeze] provides the ability to go back. 
     43 
     44== The let's prepare that demo situation == 
     45 
     46When preparing a demo, we want to be able to "save" the state of the Rock project every time some project has been made 
     47 
     48The workflow would be to branch out from the autoproj/ repository into a "demo" branch and use autoproj commit every time some progress is made.  
     49 
     50== The It's Working ! Moment == 
     51 
     52That's a job for autoproj tag. 
     53 
     54== Releasing Rock == 
     55 
     56As you may have noticed, all the different tools are basically the generation of a 50-versions.yml file in autoproj/overrides.d plus various manipulation of the git repository state. The Rock release mechanisms would be no different basically: 
     57 
     58 - a new release is a new 'autoproj tag' pushed in rock-core/buildconf 
     59 - it is also saved as a commit on the 'stable' branch of rock-core/buildconf 
     60 - switching releases is basically doing an autoproj reset --freeze <RELEASE TAG>, except that we might get the tags from the rock-core/buildconf repository regardless of the repository used for autoproj/. 
     61 - in addition to 50-versions.yml, we should create a README.txt or RELEASE_NOTES.txt that can be extracted and displayed to the user when he wants to know about the release (e.g. before deciding to switch) 
     62 
     63= Where do we go from there ? = 
     64 
     65 - first of all, we need to agree on everything that is above 
     66 - then, we should re-release rock1408 using the method so that interested rock developers can try it out 
     67 - and finally we should create a new release with the new method