Open eldir opened 1 month ago
I think I understand what was causing this. It seems like version tags like v0.1
are ignored but v0.1.0
does correctly increase the version. Does this have to do with having enable_prerelease_mode
enabled?
What I don't understand however is why this would have cause a minor version bump the commit dev_build
got auto versioned to v0.13.1
with these settings
Using enable_prerelease_mode
prevents the next suggested version from ever incrementing 0 -> 1. It does this by "demoting" major changes to minor and minor to patch. Patch changes are unaffected. It is designed for projects which are still at version 0
(so like basically half the code that runs in production :) to prevent them from being launched "accidentally".
When you tag a commit with a version tag, you override whatever was going on before. When using prerelease mode you can either assign a v1.0.0 tag when you're ready to release which will start you off at v1.0.1 suggested for the next commit or remove the setting and make sure you have a major type commit included. (I usually mark the commit that removes it as something like Remove prerelease mode to prepare for v1 release (MAJOR)
).
We do not use partial tags like v1
, v0.1
at all. It is a somewhat common practice to assign these to the latest applicable commit, so you'll have v1
and v1.23.7
pointing to the same commit and that wouldn't work as a stable reference point in any case.
v prefixed tags seem to be ignored: Standard main/development branch setup, I've added version tags here in two places to test this and the version output for the last commit here is '0.7.46-alpha.135'![image](https://github.com/user-attachments/assets/96c44148-daf6-4e07-ab67-1fb2a3d1696f)
Workflow settings:
Workflow output for the above step:![image](https://github.com/user-attachments/assets/aec4d709-52fd-4ff0-a8b8-ecd32ce1dc5e)