github.com/wallyworld/juju@v0.0.0-20161013125918-6cf1bc9d917a/doc/juju-core-release-process.txt (about)

     1  Introduction
     2  ------------
     3  
     4  This document outlines the steps for producing a juju-core release.
     5  
     6  Step 1. Prepare release notes
     7  =============================
     8  
     9  The release notes are prepared in Google document form, for easlier colaboration with juju-core and provider authors. A sample release note document is here
    10  
    11  https://docs.google.com/a/canonical.com/document/d/1Vnf2_sDtxZYaFRE7B0hY_f9FHxAOgximUj6UaJ5NyuE/edit#
    12  
    13  Generally new documents are created using the 'make copy' function.
    14  
    15  This is generally done earlier in the week with a release on the weekend, this is purely by convention.
    16  
    17  Look on https://canonical.leankitkanban.com/ and launchpad for items which have been fixed during the release.
    18  
    19  Leankit cards in the Merged lane should be documented in the release notes if applicable -- many cards are for internal refactoring or work which has no customer visible effect; they can be omitted.
    20  
    21  LP Bugs marked fixed comitted should be similarly documented and moved to fixed released. Bugs in progress should be moved to the next milestone (and milestone created if necessary).
    22  
    23  note: this process does admit the real possiblity that commits which have no leankit card or LP bug, will be missed. 
    24  
    25  Step 2. Tag the release
    26  =======================
    27  
    28  Most juju-core components do not have tags, but goose and juju-core do. 
    29  
    30  Tag the juju-core and goose repos with `juju-x.y.z` tag, if you don't have permission to tag directly on the repo talk to jam who runs the bot.
    31  
    32  Don't try to submit a merge proposal with a tag, it doesn't work.
    33  
    34  Step 3. Build the release
    35  =========================
    36  
    37  For stable releases, skip this step and proceed to the tarball step.
    38  
    39  For development releases (x.y.z, where y is odd) they are packaged via a launchpad build recipe.
    40  
    41  https://code.launchpad.net/~dave-cheney/+recipe/juju-core
    42  
    43  Update the tag on juju-core and goose to match the tag produced in step 2 then kick off the build.
    44  
    45  Step 4. Build release tarball
    46  =============================
    47  
    48  Use the script located in scripts/build-release-tarball to produce a .tar.gz which contains all the source dependencies. Sign it and upload to LP.
    49  
    50  For stable release, the server team will feed this to the saucy release process and backport it previous series.
    51  
    52  Step 5. Update the version
    53  ==========================
    54  
    55  Once a release has been built againsts a version you must update the version number in 
    56  
    57  version/version.go
    58  
    59  propose it and commit it. This moves the development version to the next release number in the series.
    60  
    61  Step 6. Upload tools to the s3 public bucket
    62  ============================================
    63  
    64  For each artifact produced by the build recipe or the the server teams' release process, run scripts/release-public-tools/release-public-tools.bash $DEB_URL. This will download the .deb, extract the /usr/bin/jujud binary and upload it with the correct name to the s3 bucket.
    65  
    66  This setup requires credentials for the s3 bucket and the s3up tool (available on lp), currently, mgz and dfc have these credentials, the bucket is owned by Gustavo Niemeyer.
    67  
    68  Step 7. TEST!
    69  =============
    70  
    71  apt-get update && apt-get install juju-core should install the latest release on your system. 
    72  
    73  Test this release by bootstrapping a model in ec2, and do a basic wordpress + mysql deployment. If you can relate wordpress and mysql, expose wordpress and get to the public address on the wordpress setup screen, this release is a success.
    74  
    75  If this step fails then this release is a failure and the release number is unused. Do not reuse release numbers. It is ok to have gaps in the sequence, we've done it before, water is still wet.
    76  
    77  The previous paragraph is mostly relevant for devel releases. For stable releases they are branched from a known working devel branch and then fed through the launchpad build process then backported into ppa:juju/stable so there is far less chance that they will be a failure.
    78  
    79  Step 7. Publish the release notes to launchpad, closing the milestone
    80  =====================================================================
    81  
    82  Publish the text of the release notes to LP, close the milestone.
    83  
    84  Step 8. Announce the release
    85  ============================
    86  
    87  Announce the release to juju-dev@lists.ubuntu.com juju@lists.ubuntu.com and canonical-juju@lists.canonical.com, copying and pasting the body of the release notes.
    88  
    89  A sample release note is here
    90  
    91  https://lists.ubuntu.com/archives/juju-dev/2013-August/001338.html
    92  
    93  Step 9. Upload tools from the s3 bucket to all other CPCs
    94  =========================================================
    95  
    96  Procedure unknown.