Repository navigation
Improvement: Single source of version truth #424
Description
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...
Activity
github-actions commentedon Mar 29, 2022
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.
jacksbox commentedon Apr 7, 2022
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:
jacksbox commentedon Apr 7, 2022
@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?
danth commentedon Apr 8, 2022
If tags are always created, regardless of the
version_sourcesetting, then it would make sense to only use those to read the version.jacksbox commentedon Apr 11, 2022
@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)
github-actions commentedon May 3, 2022
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.
triplem commentedon May 23, 2022
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.
github-actions commentedon Jun 14, 2022
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.
bernardcooke53 commentedon Aug 29, 2022
@jacksbox I'm working my way through refactor & would love your input (+ feedback down the line) - I have #487 open for it
github-actions commentedon Sep 20, 2022
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.
nejch commentedon Nov 4, 2022
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.
relekang commentedon Nov 4, 2022
@nejch I think this is already happening as a part of #487 👍
bernardcooke53 commentedon Nov 4, 2022
This is definitely happening in #487 - it will be tags only. @nejch the Gitlab implementation in PSR is definitely lagging behind Github and Gitea - would be great to have your input!
github-actions commentedon Mar 26, 2024
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.
codejedi365 commentedon Mar 30, 2024
Implemented with the release of
v8.