yarikoptic
commented
1 year ago I think for software which is a library or a tool providing some API or CLI intended to be used by other tools etc, it is important to provide "compatibility" version, such as MAJOR. in semver. Also, similarly, git-annex uses COMPAT_MAJOR.DATE such as 10.20230626. My point is that for any of the versioning schemes chosen, there should indeed be clear way to annotate with github labels on what affect label should have on a component of the version.
NB shameless plug: largely due to never resolved #1294 which hindered cutting many releases, in DataLad project we developed an "auto-ispired" https://github.com/datalad/release-action which has similar to auto labeling feature, but uses https://github.com/nedbat/scriv for more versatile changelog entries management.
hipstersmoothie
Is your feature request related to a problem? Please describe.
This issue is related to where #1957 was heading toward at the end of the thread, so tagging @laughedelic @JReinhold here. Some software packages and non-software projects use different schemes than semver, for instance unitary/alphabetical release, calver, or mixed semver-calver
For instance, we're starting a documentation project that would benefit from receiving a mixed semver-calver versioning, e.g. YYYY.patch
While this is an easy non-semver version to feed to auto (cause it's still bendable into XX.YY.ZZ), having a proper YYYY.patch verison is not possible at the moment. Is there interest in generalising the versioning scheme and add calver-related enhancement? I'm also thinking about other projects, for instance what you peeps are doing @oesteban @yarikoptic @handwerkerd
Describe the solution you'd like
Describe alternatives you've considered https://github.com/marketplace/actions/calver-release
Very brief consideration: all of our repos are based on auto, and there are just way too many features (e.g. automatic changelog) that we don't want to loose!
Additional context