search

jmongard / Git.SemVersioning.Gradle

Gradle plugin for automatically versioning a project using semantic versioning and conventional commits with change log support based on git commit messages.
https://plugins.gradle.org/plugin/com.github.jmongard.git-semver-plugin
Apache License 2.0
38 stars 4 forks source link

Incorrect versioning when merging between two branches #60

Open j-choi1 opened 1 week ago

j-choi1 commented 1 week ago

Assume default semver config and we have two branches: master and develop

master current version is 1.0.0 and develop is a copy of the master branch.

Example 1:

  1. In develop, commit feat: and merge develop into master via PR.
  2. In master, run releaseVersion which will release 1.1.0.
  3. Merge master into develop via PR.
  4. In develop, commit fix: and run printVersion which will show 1.2.0.

In step 4, shouldn't the version print out 1.1.1?

Example 2:

  1. In develop, commit feat!: and merge develop into master via PR.
  2. In master, run releaseVersion which will release 2.0.0.
  3. Merge master into develop via PR.
  4. In develop, commit fix: and run printVersion which will show 3.0.0.

In step 4, shouldn't the version print out 2.0.1?

j-choi1 commented 1 week ago

I also noticed for changelog that it'll include the previous release commits. For example:

  1. In develop, commit feat: and merge develop into master via PR.
  2. In master, run releaseVersion
  3. Merge master into develop via PR.
  4. In develop, commit fix: and run printChangeLog You will see that the feat commit made in step 1 got included but it should not do that. It should only show the fix commit.
jmongard commented 1 week ago

Hi, This problem you describe is not that easily fixed. It caused by the long lived development branch. The plugin works by walking the tree from the head commit and following the tree into every branch that precedes it. If the plugin find a release commit or tag it stops and return the version. Whit a long living develop branch the plugin finds the 1.1 version from master and 1.0 from develop including feature changes (that were already used to calculate 1.1 but it does not know that). What I can do is to ignore changes that come from branches based on an older version but that would break feature branches based on older versions. So if you are just using main and develop I could add a setting that would make the plugin ignore branches based on older versions?

j-choi1 commented 1 week ago

If you release from master and then merge master into develop, the release commit history carries over to develop so the plugin should know the last release commit version. This is a very big limitation with the plugin that it only works using one branch.

jmongard commented 1 week ago

I think I found a better way of elimination duplicate commits. I changed so the plugin continues scanning commits after a release commit is found and just mark them as read already if there are more than one branch. The change is included in 0.12.10 release.

jmongard commented 1 day ago

Have you by any chance had time to test the latest release? I think it will resolve your issue.