Skip to content

Release Instructions

Jump to bottom
Tom Mitchell edited this page May 15, 2017 · 8 revisions

Testing a GCF Release

  1. Run: gcf-test.py

  2. With no aggregates defined on the command line or in your omni_config ensure the following returns a version for each aggregate:

    ./omni.py -f <pg-utah> getversion
./omni.py -f <plc> getversion

  3. With no aggregates defined on the command line or in your omni_config ensure the following returns a resource for each aggregate for which we got a version in the previous step:

    ./omni.py -f <pg-utah> listresources
./omni.py -f <plc> listresources

  4. Run the following cases (or the equivalent therefore):

    1. api-test.py -f <pg-utah> -a <myplc aggregate url>
    2. api-test.py -f <pg-utah> -a <PG aggregate url>
    3. api-test.py -f <plc> -a <myplc aggregate url>
    4. api-test.py -f <plc> -a <PG aggregate url>

  5. Create a sliver using native RSpecs at some AM

Creating a GCF Release

This section explains how to make a release of the GCF software.

Note we assume that "origin" points to Github: [email protected]:GENI-NSF/geni-tools.git.

Pre-checks

  1. Make sure BOTH README-omni.txt and CHANGES are up to date.

    To check that CHANGES is up to date, try this git command:

    git log v1.6.2... --no-merges --format="%ce %cd %s %b %N" --reverse --stat

    Substitute the appropriate last version tag-name.

    Be sure that there are GCF tickets for each (significant) item that changed/was fixed and that these are targeted at the right milestone, that you are noting in CHANGES

  2. Make sure the version is set:

    omni.py --version

  3. Make sure the windows_install/LICENSE.txt is up to date.

    We are required to list all 3rd party packages that we are including, and include the correct license file. Check the license file that all dependent packages are listed with the proper versions and licenses, plus the URL where the binary can be retrieved. Note that all packages must be currently retrievable there - if not, then you must use a different version. If there are any changes to version numbers, licenses, or included packages, then submit this to Mark (who may then submit it to Bill Quantrille in contracts for written approval).

    Note that any change to the required packages should also be noted in the appropriate INSTALL files.

Create the tarball

  1. Make sure you are in the gcf directory (otherwise the tarball won't contain the correct files):

    pwd

  2. Make sure your local repository is up to date:

    git checkout master
git fetch origin
git merge origin/master
git checkout develop
git merge origin/develop

  3. Create a release branch

    Release branches are created off of develop. Releases are tagged on the release branch. When the release is final, the release branch is merged on to both master and develop.

    git checkout develop
git checkout -b release-2.5
git push origin release-2.5

  4. Create a tag for the release.

    An example of a final release:

    git tag -a -m "gcf 1.0.1" v1.0.1 release-1.0.1

    An example of a candidate release:

    git tag -a -m "gcf 1.0.1-rc1" v1.0.1-rc1 release-1.0.1

    Don't forget to push the tag.

    git push --tags origin

    (You can check the tags in your repo with: git tag)

    (Also delete mistakenly added tags in your local repo with: git tag -d badtag)

  5. Create the tar bundle (note the trailing slash in the prefix arg):

    (Alternative: simply use the tarball Github automatically creates for tags here: https://github.com/GENI-NSF/geni-tools/tags )

    Here is the basic form:

    git archive --prefix=gcf-VERSION/ TAG > gcf-VERSION.tar

    A example of a final release:

    git archive --prefix=gcf-1.0.1/ v1.0.1 > gcf-1.0.1.tar

    An example of a candidate release:

    git archive --prefix=gcf-1.0.1-rc1/ v1.0.1-rc1 > gcf-1.0.1-rc1.tar

  6. Check the tar file to make sure it has the right directory prefix AND contains the expected items in the top level gcf directory (like INSTALL and the src directory):

    tar tf gcf-1.0.1.tar | less

  7. Compress the tar file:

    gzip gcf-1.0.1.tar

    You now have a file named gcf-1.0.1.tar.gz.

Have the release Tested and Released

  1. Post the release candidate and iterate

    1. Open a ticket, e.g.: Release GCF 1.3. Be sure to note if there were changes to the license file or not, where the file is, and if there were changes to the file, whether you have gotten approval from Bill Q (via Mark) for the updated file. Note the date of the last license approval and who approved, and any changes since then. Be sure to cc Mark & Marshall on the ticket.
    2. Tag v1.3-rc1 per above
    3. Attach that tarball to the ticket, assigned to Luisa for testing
    4. Point Infra at the ticket, to have them test amcanary with the new release
    5. Iterate with Luisa and Infra
    6. When Luisa approves and Infra finds no problems, it is time to build the Windows & Mac binaries and attach those. See wiki:SwReleaseGcf/MacOS and wiki:SwReleaseGcf/Windows
    7. When Luisa finds no issues with these binaries. tag a clean v1.3 at the same point as the approved RC, and attach that tarball to the ticket for posting. Also attach new windows and mac binaries for the clean tag point.

  2. Get the release approved and posted

    • Once Luisa says the release is ok, and you've posted a non-RC version on the ticket, she verifies that it is the same as what she tested
    • Then she passes it to Heidi
    • Once Heidi signs off, Infra posts it
    • Then Luisa verifies the right thing was posted ok.
    • Then you are ready to merge the release branch on to master and develop, and delete the release branch

  3. Merge the release branch

    git fetch origin -p
git checkout master
git merge origin/master
git merge --no-ff release-2.5
git push origin master
git checkout develop
git merge origin/develop
git merge --no-ff release-2.5
git push origin develop

    Update the trac repo as well if desired.

    Delete the release branch

    git branch -d release-2.5
git push origin :release-2.5

    Switch to the develop branch for ongoing development

    git checkout develop

  4. Update the version number to prepare for the next release.

    See EG: https://github.com/GENI-NSF/geni-tools/commit/f757f53e20451194438b1b7d32450dc9e1fca1cc

    • git checkout develop
    • src/gcf/gcf_version.py edit GCF_VERSION
    • Add a section in CHANGES
    • Add a section in README-omni.txt for release notes
    • INSTALL.txt: 3 sample commandlines
    • windows_install/package_builder.iss (7 places)
    • mac_install/addAliases.command (6 places)
    • mac_install/INSTALL.txt (2 places)
    • mac_install/makeMacdmg.sh (1 place)
    • agg_nick_cache.base - update the date at the top and the current release number
    • configure.ac
    • README-packaging.md

  5. Update Wiki pages

    Note that these pages should transition to github.

  6. Send email announcing the new release

  7. Do NOT close the ticket (the infra group will close it)

    • Luisa should have the ticket to verify wiki edits

  8. Create a release on Github

    • https://github.com/GENI-NSF/geni-tools/releases
    • Hit Draft a new release
    • Pick the proper tag
    • Title release something like Stitcher / Omni version 2.9
    • Give the release a nice description, using text from the announcement email
    • Attach the Windows and Mac binaries
    • Preview, then Publish

GENI is sponsored by the National Science Foundation.

Home

Omni

Install

Developer

Release

Clone this wiki locally