Release process

Every release comes from the necessity to address bugs, add or change features. With that in mind every release has a testing phase of days or weeks, depending if it's a minor/patch version or a major, as per semver

Release schedule

Releases are scheduled bi-weekly for minor/patch versions. Major version may take a month or two, depending on the version load.

You may see the scheduled milestones here. You can also see the planning in our Trello board.

Naming convention

Releases are labeled as stable, current.

• stable releases are available on a monthly basis (major releases, minor). These releases are considered stable as these are the result of weeks of minor and patch revisions.

• current releases always point to the latest released version. A new release is often available bi-weekly (minor, patch versions).

Branching

• master Last stable release.

• develop Anything ready for next release (minor, patch).

• next Work in progress for next minor release.

Release schedule for each channel is independent from one another. A release for current doesn't mean a release for stable.

stable releases comes from master meanwhile current releases from develop. There is not a release for next as it's merged into develop before a minor or major release.

Process step-by-step

VERSION=$VERSION make release  # $VERSION is in the form: v1.2.3
# Will update VERSION file with release version
# A new branch release/${VERSION} will be created

# Antigen will be built and cram tests run

# vi will open up with CHANGELOG.md file loaded
# Edit the CHANGELOG.md with relevant information for the release

# Current changes in README.mkd, CHANGELOG.md and
# bin/antigen.zsh will be commited into a release branch

VERSION=$VERSION make publish
# Release branch will be pushed upstream

Once you push release/${VERSION} create a new PR to develop.

If everything is OK, merge into develop this way:

git checkout develop
git rebase -i release/${VERSION}

# Sign release and publish
git commit -S --amend
git push upstream develop

Once develop is up-to-date create a new tag and a GitHub release:

VERSION=$VERSION make deploy
# ${VERSION}.tar.gz and ${VERSION}.tar.gz.sign will be created
# .tar.gz and .sign must be added as a release artifact

# make deploy will create a ${VERSION} tag and push it to upstream

Release signing

We currently sign our releases with the following key: 0xD7CF4E0C28A9979E.

In order to verify our releases you'll need to retrieve our release keys:

gpg --recv-keys 0xD7CF4E0C28A9979E

Do verify by issuing the following commands:

zcat {VERSION}.tar.gz | gpg --verify {VERSION}.tar.gz.sign -

If everything is OK it should print:

gpg: Signature made Sat 08 Apr 2017 03:59:18 PM -03 using RSA key ID 28A9979E
gpg: Good signature from "Darío Cavuotti <[email protected]>"

Release checklist

• Address all PR and Issues
• Draft Release Announcement
• Make release, publish and deploy
• Update gitter channel message
• Update website