Implement CLI option to base versioning on latest tag only

[AmirLavasani]

Implement CLI option to base versioning on latest tag only

[codejedi365]

@AmirLavasani, can you provide more detail on what you were trying to do when the version number reset? If you could use a Git Clients visualization graph functionality or the command git log --graph --decorate --oneline --all on the before state of your repo and then an after state of the branch rebased (or contrived example). If your project is open source, can you provide a link to your repo? Also can you provide the log of your command in debug mode, a pip freeze output and your semantic release configuration (basically all the components of a bug report, please check the bug report for the full list)

I rebase branches all the time and I have not seen this type of behavior before. Also as of v8, PSR does not evaluate commit messages for its version determination algorithm, it only uses tags. When evaluating tags it does grab the underlying hash the tag points to but that is irrelevant as nothing is cached between executions. PSR evaluates the repo and its tags as it stands at that moment.

There is one known bug in the algorithm which I am working on fixing but the result you describe is not the known incorrect behavior.

[AmirLavasani]

Thanks @codejedi365

My rebase process might not have followed the standard procedure. I manage a repository that serves as a template code base, and several projects are derived from it. Whenever the template repository gets updated, all other services based on it undergo rebase to align with the latest template base code.

Let me try whether I can reproduce the version reset issue by rebasing with a branch within the same repository.

[codejedi365]

I manage a repository that serves as a template code base, and several projects are derived from it. Whenever the template repository gets updated, all other services based on it undergo rebase to align with the latest template base code.

Now I understand why you are running into that issue. All of your old tags are now not in the new branch history (all the way to the origin commit) that you are now release from.

I've worked with template updating before and it's not an easy problem to solve. To maintain the integrity of the derivative projects and their previously released tags you have to either use a merge commit on top of the repo and only choose the desired new configuration. You can also try to use a published library instead as the foundation code and in your derivative projects import it as a dependency that can be version bumped. An example in the JavaScript ecosystem is the create-react-app project which sets up projects from a template that depend on the react-scripts dependency library. This library has most of the configurations included in it.

Rebasing is nice to show the foundation changed but this really eliminates the integrity of what was released before.