Releases about pypesto HOT 8 CLOSED

Auto-deploying version-tagged commits

is already done.

from pypesto.

The develop branch is now also monitored on readthedocs (https://pypesto.readthedocs.io/en/develop/), so that merges to develop will automatically trigger doc builds. and we will notice doc build failures and can check before releasing.

from pypesto.

true. the latest version on the master can be newer than that on pypi, if the version was not updated in the last pull request (e.g. bc it was just a minor thing updated, not qualifying for a new version yet). what exactly do you mean by "releases that tag versions"? can this be done automatically?

from pypesto.

Agreed with @FFroehlich .

Whenever a new release is uploaded to pypi, there should also be a github release created. This will create a git tag and save the release on zenodo.

from pypesto.

It is true that with the current system there will be multiple versions with the same version number in master. This is not great, but we can live with it. At least one can find the exact commit of the release back from the tag.

To avoid multiple versions with the same version number in master, we change our release process:
All feature pull merge requests go to develop, which is the main line. From there we create release branches which get new version numbers, and only those are merged into master, and nothing else. As nicely illustrated here. This is what we are currently aiming for in https://github.com/ICB-DCM/AMICI .

from pypesto.

Sounds good. I agree. Should also be documented in https://pypesto.readthedocs.io/en/latest/deploy.html.

from pypesto.

I would rather set up an automatic deploy script. Should be really straightforward as we dont have any cpp/swig dependencies https://docs.travis-ci.com/user/deployment/pypi/

from pypesto.

Will look into

• Updating contrib guide for github releases
• Updating contrib guide for auto-closing commits
• Auto-deploying version-tagged commits

from pypesto.