Releasing eggs

Introduction

We maintain two egg distributions:

  1. Quaive private enterprise edition on pypi.quaive.net
  2. Ploneintranet community edition on pypi.python.org

Each of those is managed on a separate release branch. Quaive is currently on branch 1.3.x (Jupiter), Community is on 1.2.x (Mars).

These branches are needed so changes made during the release process are QA controlled via the normal pull request process.

Note

External theme resource package Since version 1.2.0a3, we depend on the pacakge quaive.resources.ploneintranet.

Note

Changelog Since version 1.2.69 we maintain the changelog manually, see https://github.com/quaive/ploneintranet/issues/1416 for details.

Creating a release

This shows how to cut a private 1.3.x release from master:

user@host:~$ git checkout master
user@host:~$ git pull origin master
user@host:~$ git checkout release-1.3.x
user@host:~$ git pull origin release-1.3.x
user@host:~$ git merge master

Now you can start the release process:

user@host:~$ bin/prerelease
Run pyroma on the package before tagging? (Y/n)?
INFO: ------------------------------
INFO: Checking /home/ale/Code/plone/ploneintranet
INFO: Found ploneintranet
INFO: ------------------------------
INFO: Final rating: 10/10
INFO: Your cheese is so fresh most people think it's a cream: Mascarpone
INFO: ------------------------------
Do you want to run check-manifest? (Y/n)?
lists of files in version control and sdist match
WARNING: Found more than one file, picked the shortest one to change: CHANGES.rst, docs/about/history.rst
Enter version [1.3.x]:
INFO: Running command to update news: /home/ale/.local/bin/towncrier --version 1.3.x --yes
Loading template...
Finding news fragments...
Rendering news fragments...
Writing to newsfile...
Staging newsfile...
Removing news fragments...
Removing the following files:
/.../ploneintranet/news/...
...
Done!

Be sure that pyroma returns you a rating of 10/10 and that check-manifest reports “lists of files in version control and sdist match”.

If not please fix this.

Also check that the changelog file (CHANGES.rst) contains valuable informations and it is readable and that the news folder is empty.

Commit your changes and continue:

user@host:~$ bin/release
INFO: Starting release.
Tag needed to proceed, you can use the following command:
git tag 1.3.x -m "Tagging 1.3.x"
Run this command (Y/n)? Y
Check out the tag (for tweaks or pypi/distutils server upload) (Y/n)? Y
Register and upload to pypi (Y/n)? n
Register and upload to quaive (Y/n)? Y
Register and upload to cosent (Y/n)? n

Please make sure to not push a private release to pypi.python.org!

The new release is now available on pypi.quaive.net

Now push your commit:

user@host:~$ bin/postrelease
INFO: Starting postrelease.
Enter new development version ('.dev0' will be appended) [1.3.x+1]:
OK to commit this (Y/n)? Y
OK to push commits to the server? (Y/n)? Y

Merge the release changes

Please submit a new pull request from the release branch into master (go to https://github.com/quaive/ploneintranet/compare/release-1.3.x?expand=1). Do not delete the release branch, it will be re-used for subsequent releases.

See Git workflow for a full description of the Git workflow.

Update the Jupiter deployment

We want to quality-check the new egg release by running a CI test on it.

If you don’t have a jupiter build already, initialize it, see below.

The Jupiter buildout assumes that it’s buildout.d directory is identical to the ploneintranet buildout.d directory. If your release involved a change in ploneintranet/buildout.d e.g. a Plone upgrade, a new version pinning, or a new solr field, copy all the buildout.d configs to jupiter:

cp buildout.d/* ../jupiter/buildout.d/  # or wherever your jupiter build lives

Now go to jupiter, update the ploneintranet pin:

cd ../jupiter  # or wherever your jupiter build lives
sed -i 's/ploneintranet = .*/ploneintranet = 1.3.x/' buildout.cfg
git commit -am 'Release 1.3.x'

Obviously you’re supposed to change the release number to match the actual release you created above!

Finally, trigger a CI build by pushing the change:

git push gitlab master
git push origin master

Initializing a Jupiter deploy build

If you don’t have a jupiter build already, check it out:

git clone git@github.com:quaive/gaia.git

Add a remote for Gitlab pushes:

git remote add gitlab git@gitlab.com:quaive/gaia.git

Using a private egg release

To your non-public project buildout.cfg:

[buildout]
find-links +=
    http://user:password@pypi.quaive.net/packages/

# we want to pull in development releases
prefer-final = false

You can use the jupiter egg based deployment as a template.

Update quaive.resources.ploneintranet

This process requires to clone separetely quaive.resources.ploneintranet and releasing it to pypi.quaive.net:

git clone git@github.com:quaive/quaive.resources.ploneintranet.git
cd quaive.resources.ploneintranet
make all
fullrelease

Take note of the released egg version, and update the file buildout.d/versions.cfg in order to match it, e.g.:

[versions]
# Quaive packages
quaive.resources.ploneintranet = 1.2.0a1

Make a pull request to quaive/ploneintranet with this changes.

Managing users on pypi.quaive.net

You can only add users if you have shell access:

user@host$ ssh pypi@pypi.quaive.net
pypi@cs02:~$ cd pypiserver/
pypi@cs02:~/pypiserver$ htpasswd var/quaive/htpasswd.txt johndoe
New password:
Re-type new password:
Adding password for user johndoe

Ask Guido to add your users if you do not have ssh access.