Changes between Version 1 and Version 2 of ReleaseManager


Ignore:
Timestamp:
04/01/12 13:08:34 (8 years ago)
Author:
magnate
Comment:

First draft

Legend:

Unmodified
Added
Removed
Modified
  • ReleaseManager

    v1 v2  
    55 * the roadmap for the X.Y.0 milestone 
    66 * the existing tickets for the X.Y.0 milestone 
    7  * the public aspirations of any active devs 
     7 * the public aspirations of any active devs (though these should be captured as tickets) 
     8 * also check the Triage tickets for any that you can personally triage - if they are platform-specific and you can't, then don't worry about them 
     9 
     10After checking with other devs to see who is likely to be able to contribute features, triaging or bugfixes in your chosen timescale, update the "Goals for X.Y" page with a definitive statement of what you expect to see in X.Y.0, including a list of tickets that you really want closed - note that this is unlikely to be the full set of tickets tagged for X.Y.0. Other people can take stuff out (e.g. if they aren't going to be able to finish it in time), but nobody can add anything else in without your agreement. 
     11 
     12When you're happy with it, or you run out of patience with the owners of outstanding tickets, declare a Release Candidate (RC):  
     13 * on the master branch, run "git tag -a X.Y.0-RC1" and then "git push official tag X.Y.0-RC1" 
     14 * announce the RC on oook, linking to the build at http://buildbot.rephial.org/builds/master/builds.html 
     15 * allow at least two weeks for people to playtest it 
     16 
     17If there are confirmed, reproducible bugs in the RC, make sure people make tickets for them, and see if anyone can fix them. Once all the important bugs are fixed to your satisfaction (you may choose to leave tiny ones), repeat the process above for RC2. If that turns up major bugs, repeat for RC3 and so on. 
     18 
     19= Releasing X.Y.0 = 
     20Once you are happy with an RC as bug-free, declare it as X.Y.0 by following the process on the ReleaseChecklist page. For the X.Y.0 release, you will also need to create a new branch for that series with "git checkout -b X.Y-release" and "git push official X.Y-release". You are the owner of this branch and the only person who should push to it. Development of X.Y+1-dev will continue in master - this branch is solely for the creation of X.Y.1 and any subsequent releases. 
     21 
     22= Releasing X.Y.1 et seq. = 
     23If you are extremely lucky, your RCs will have found all the bugs, and your job is done. More likely, since many more people play a .0 release than an RC, new bugs will be reported. Again, make sure there are tickets for any that can be reproduced reliably, or (even if they can't) for those reported by more than one person. These tickets should use the X.Y.1 milestone. It isn't your job to fix them all, but to draw them to the attention of those who can. 
     24 
     25When you're ready - maybe when there's a tailing-off of new bug reports, and no really nasty ones remain - repeat the above process for X.Y.1-RC1. With luck you won't need more than one RC for any .Z release. If it's just a fix for a single show-stopping bug (for example, if some idiot made leather boots ten times as common as they should be), you may decide to skip an RC altogether. 
     26 
     27When you're happy to release, don't forget to go through ReleaseChecklist again. 
     28 
     29Don't be tempted to add new features to .Z releases; they are for improved performance of the .0 feature set. If people want to rush to release a fancy new feature, tell them to step up as RM for the X.Y+1 series and do it themselves.