We really do not need a release branch for this package about pytest-pyvista

[adeak]

Oops, I came here via email notification and didn't notice this wasn't the pyvista main repo... Sorry, and please ignore my concerns (but I'll read your detailed reply later when I get the chance).

[banesullivan]

didn't notice this wasn't the pyvista main repo

All good! I find it useful to document these things either way

FYI, we won't be getting rid of release branches for the main PyVista repo anytime soon - PyVista is an excellent example of where it makes sense to use release branches

[MatthewFlamm]

I'm +1 for making it simpler here. Although when I released here, it was pretty painless other than bumping version numbering. But any friction is bad if it is unneeded.

[adeak]

I want to add that, AFAIK, using setuptools_scm is one of the most common practices for package versioning in Python

That's a bit surprising because I've never heard of it (which is not a very strong statement, mind you). I took a quick look around the "big" libraries I usually have around (numpy, scipy, matplotlib, pandas, sympy) and only matplotlib uses it. In any case if it would be useful, it should be fine.

[adeak]

I don't feel qualified to give an opinion here as I don't actually manage releases. It took me long enough to figure out the current release model.

Can you explain a bit about the new workflow? And

1. In what way do release branches add overhead?
2. How would hotfixes for patch versions work without dedicated branches? Wouldn't a lack of release branches make releases a bit of a moving target? Conversely, could we still keep out certain PRs from a release should we wish to?
3. I love having a PR for releases with release notes previews; there's often stuff that needs correcting (e.g. [breaking-change] labels that are kind of important with our development model). Would this have to go away?

[banesullivan]

In what way do release branches add overhead?

We have to open a PR and/or merge what's getting released onto the release branch, where the version string is then manually updated, pushed, then tagged. Too many steps when we are 100% of the time merging main onto the release branch here.

How would hotfixes for patch versions work without dedicated branches?

That's the thing. There would only be one maintained version of the package, latest. As patches come in, main is tagged and released. For a small package like this, we aren't going to maintain and patch release versions separately... IMO, that only makes sense for much bigger projects like PyVista that see way more active development. As soon as bugs are fixed here, they need to be released (see all recent PRs for examples).

Conversely, could we still keep out certain PRs from a release should we wish to?

Nope. While we do this on PyVista, it just doesn't make sense here. This package is too small, and there should only be one maintained version: latest... I want to emphasize this what we are already doing here in practice... just with extra steps.

I love having a PR for releases with release notes previews; there's often stuff that needs correcting (e.g. [breaking-change] labels that are kind of important with our development model). Would this have to go away?

The PRs would go away, but the release notes listing all the changes would still get generated on the GitHub Release itself.

---

If we switch to use setuptools_scm, this makes versioning completely automated:

The advantage of this approach is that you never have to hard-code a version. The version numbers are created when installing it (e.g., pip install -e . or similar) and placed in pytest-pyvista/version.py.

Example of version numbers:

• Released versions will match the git tag : 0.2.0
• GitHub commits add .dev#+hash : 0.2.0.dev4+g2785721
• Uncommitted changes add timestamp : 0.2.0.dev4+g2785721.d20220727

This makes it so we can just tag main, and a release will get generated. Frictionless.

[banesullivan]

I want to add that, AFAIK, using setuptools_scm is one of the most common practices for package versioning in Python

[banesullivan]

What we have implemented here (adopted from practices set for PyVista) is adopted from trunked based development which is tailored to large projects with lots of active development: https://trunkbaseddevelopment.com/branch-for-release/