Releasing eggs


We maintain two egg distributions:

  1. Quaive private enterprise edition on
  2. Ploneintranet community edition on

Each of those is managed on a separate release branch.

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


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


Changelog Since version 1.2.69 we maintain the changelog manually, see for details.

Creating a release

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

First, prepare the release branch:

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

You may need to work around zestreleaser.towncrier breakage:

user@host:~$ . bin/activate

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 [2.1.x]:
INFO: Running command to update news: /home/ale/.local/bin/towncrier --version 2.1.x --yes
Loading template...
Finding news fragments...
Rendering news fragments...
Writing to newsfile...
Staging newsfile...
Removing news fragments...
Removing the following files:

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 2.1.x -m "Tagging 2.1.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!

The new release is now available on

Now push your commit:

user@host:~$ bin/postrelease
INFO: Starting postrelease.
Enter new development version ('.dev0' will be appended) [2.1.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 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 Saturn deployment

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

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

The Saturn buildout assumes that its 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 Saturn:

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

Now go to saturn, update the ploneintranet pin:

cd ../saturn  # or wherever your saturn build lives
sed -i 's/ploneintranet = .*/ploneintranet = 2.1.x/' buildout.cfg
git commit -am 'Release 2.1.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 Saturn deploy build

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

git clone

Add a remote for Gitlab pushes:

git remote add gitlab

Using a private egg release

Prepare your ~/.pypirc that contains the instructions to authenticate to the private egg repository:

index-servers =


Add the this line to your buildout.cfg:

find-links +=

If you want to install the latest ploneintranet alpha/beta releases add:

prefer-final = false

or pin the ploneintranet version you desire, e.g.:

ploneintranet = X.Y.ZaN

Instead of creating a ~/.pypirc file, you can add the credentials to the URL in the find-links option, e.g.: In this case remember to keep the file safe :)

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

Update quaive.resources.ploneintranet

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

git clone
cd quaive.resources.ploneintranet
make all

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

# Quaive packages
quaive.resources.ploneintranet = 1.2.0a1

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

Managing users on

You can only add users if you have shell access:

user@host$ ssh
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.