Versioning releases - Githubissues

BirdVox / birdvoxdetect

A pre-trained deep learning system for detecting bird flight calls in continuous recordings

MIT License

78 stars 15 forks source link

Versioning releases #9

Closed justinsalamon closed 5 years ago

justinsalamon commented 5 years ago

Just noticed how we're versioning/naming releases. Perhaps it's worth adhering to conventions here, which means:

Each release version follows semver MAJOR.minor.bug convention, e.g. 0.1.0 instead of 0.1
No white space in release names, i.e. 0.1.0.beta or 0.1.0.rc0 instead of 0.1 beta (for pre-releases I prefer using rcX instead of beta because it support multiple pre-releases (rc0, rc1, etc...).
Optional: release names start with a v, i.e. v0.1.0 instead of 0.1.0

Examples of following the above suggestions include the releases for librosa and scaper.

lostanlen commented 5 years ago

branch 0.1.X: version = '0.1.0' branch master: version = '0.2.dev0' i think that this is strictly compliant wrt PEP 440, and loosely compliant wrt 2.0.0.

justinsalamon commented 5 years ago

0.2.dev0 isn't compatible with semver though, right? Why not just always keep all 3 digits, i.e. 0.2.0.dev0 or 0.2.0.rc1? Anyway, up to you.

lostanlen commented 5 years ago

0.2.0.dev0 is a bit of a pleonasm because there is no such thing as a release candidate of a bugfix release. In semver, 0.2.0.dev0 would come after 0.2.0.alpha (rule 11). In general, there is no specification for developmental versions (i..e, the bleeding-edge master branch). So that would mean that we should abandon alpha releases, call our development branch an alpha release, and only do beta releases as well as release candidates.

I'm realizing that the points you originally raised refer to the titles of the release notes, not the release tags themselves. These are mutable and cannot be inspected from the code. But i'll change them anyway.

lostanlen commented 5 years ago

closed by 906aa0d