Repository navigation
Improvement: Single source of version truth #424
Description
Activity
This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.
Adding to this:
I think pre and build releases, ideally from different branches is kind of an important feature.
To enable more and better development of them, I think we should do the same thing as the (js) semantic-release and only use tags as the single source of truth for current and previous versions:- config files do not allow us to find previous versions (but we can still write the version to this files)
- commit messages can be lost with squash merges and are error prone - we could falsely identify a message as containing a version, think a message like "bumped package xyz to version 4.5.1" will already mess with our change log generation, and with the prerelease as well
@relekang @danth @williamluke4
Tagging you 3 here as you are the most active contributors or reviewed/accepted my PRs :)Also one question, is there a plan / direction where this package should develop to? And/Or is a discussion about this topic desired?
If tags are always created, regardless of the
version_sourcesetting, then it would make sense to only use those to read the version.@danth jup, tags would need to always be created. I think that is a fair requirement (in the future we could think of a plugin solution to enable different and more complex version sources)...
This breaks with a feature I introduced as well -> #341, but as stated in the PR, this was for the usecase of monorepos, something this package is currently not made for and also probably should not be used for. So I would be fine with removing this features again.
(the whole prerelease feature seems to be a lot more useful and for a bigger audience as well)Reacted by Daniel ThwaitesThis feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.
One more feedback on this one. The chamgelog seems to still rely on commit messages which would be against the single source of truth as well IMHO.
So the chamgelog should determine the log messages based on Tags as well. Meaning that all commit messages between two tags need to be retrieved.This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.
This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.
Just another voice here for using tags if possible (I see there were discussions about monorepos, but maybe another way to parse that makes sense).
I'd actually get rid of
get_current_release_version_by_commitsentirely - people use dependabot/renovate and it seems like that could always interfere when other semvers appear in commits, as well as changing commit message patterns throughout the history of a project etc. I also had trouble migrating an existing project using this approach, as there's no good way of reusing changelogs/tags to bump versions while still committing things.There seems to be some refactoring going on and I haven't full read all the context so sorry if this is a repeat :) I help maintain python-gitlab and we use each other's libraries so I'd definitely like to have things work smoothly, will try to contribute at least some gitlab-related stuff if you decide to keep that in the core library.
This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.
Implemented with the release of
v8.
Description
Note: This ticket is purely about implementation.
Currently the version numbers are determined via multiple ways depending on the config and the called method.
Depending if
get_current_version,get_next_version, and more, different ways to determine this version are used:based on tags, based on parsed commit messages, the version file (and maybe more?).
I understand the need for this in the current implementation, but it feels a bit error prone and I think it would make the code easier and cleaner if we could come up with a single way how versions are determined / parsed / found.
I would like to open a discussion about this...