Skip to content

Automatic versioning and releasing #24

@larsks

Description

@larsks

I would like to propose that we automate the process of (a) managing the version number of this project and (b) releasing new versions of the project to PyPi (with the ultimate goal of expanding these practices to other ESI related projects).

A common solution for these sorts of requirements is one of the various semantic versioning actions available on github; options include things like python-semantic-release and semver-action. These tools typically rely on the use of conventional commit messages to calculate changes to the version number.

There are a couple of workflows we could follow:

  1. Most pull requests result in a new release

    When we merge a pull request with commits containing the appropriate feat: or fix: prefixes or a BREAKING CHANGE note, that will immediately tag a new release on github and push a new release to PyPi.

  2. Releases only happen explicitly

    In this model, pull requests are merged into a development branch, and releases are generated explicitly by merging the development branch into the release branch (typically main). The version number and PyPi release process is still completely automated, but it's not triggered every time we merge a pull request.

I think I would prefer option 1; part of my goal here is to avoid the problem I've seen in a number of other open source projects in which there has been active development, but no published releases for years, making it difficult to consume the changes introduced into the repository.

If we agree this seems like a good idea, I can submit a pull request with a workflow that we can test out.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions