search

ajoberstar / reckon

Infer a project's version from your Git repository.
Apache License 2.0
187 stars 28 forks source link

Working with multiple release branches #102

Closed ctolkmit closed 2 years ago

ctolkmit commented 5 years ago

Hi,

either I am confused about using this plugin in a useful way with multiple release Branches.

Scenario:

My reckon config is:

reckon {
    scopeFromProp()
    stageFromProp('dev', 'rc', 'final')
}

I have got a project containing two Branches release/3.0.x and release 3.1.x. There are still branches release/2.0.x and release/2.1.x without using reckon, and existing tags like 2.0.7 (released, final versions) on the release/2.0.x branch.

In both 3.x branches I (manually) tagged (different) commits as 3.0.0-dev.0 and 3.1.0-dev.0 respectively.

When developing on both branches, reckon now determines useful versions like 3.0.0-dev.0.535+586704e.

I now created a release for branch 3.0.x: ./gradlew -Preckon.stage=rc reckonTagCreate That correctly created: 3.0.0-rc.1

I now switch to my release/3.1.x branch and start a build, the following happens:

$ ./gradlew clean

FAILURE: Build failed with an exception.

* Where:
Build file '/home/ctolkmit/ennit-sal-ws/mime-main/app-modules/build.gradle' line: 24

* What went wrong:
A problem occurred evaluating project ':app-modules'.
> Reckoned version 2.1.0-dev.0.537+3c310d9 is (and cannot be) less than base version 3.1.0-dev.0

Git log's latest tag is 3.1.0.dev:

ctolkmit@inferno:~/ennit-sal-ws/mime-main$ git log --oneline
3c310d95 (HEAD -> release/3.1.x) SMIME-434 testing releases
4bdd229c (tag: 3.1.0-dev.0, origin/release/3.1.x) SMIME-434 added foobar
586704e3 (tag: 3.0.0-rc.1, origin/release/3.0.x, release/3.0.x) SMIME-434 try reckon again
10688ab1 (tag: 3.0.0-dev.0, feature/SMIME-434-umstellung-edelivery-auf-die-verwendung-von-git) SMIME-434 release branch suffix is optional
fa68c2aa SMIME-434 fix release branch pattern
0ee1baeb SMIME-434 update nebula-release-plugin
e02e7ca0 (origin/feature/SMIME-434-umstellung-edelivery-auf-die-verwendung-von-git) SMIME-434 fix release branch pattern
3c62f3c7 SMIME-434 limit release branch patterns
c8acd537 SMIME-434 add nebula plugin
3e766165 Merge remote-tracking branch 'origin/release/2.1.x' into feature/SMIME-434-umstellung-edelivery-auf-die-verwendung-von-git
581fdb1c (origin/release/2.1.x) Merge pull request #261 in SHUS/mime-main from bugfix/SMIME-439-merge-to-2.1.0 to release/2.1.x
bb064c3d Merge pull request #262 in SHUS/mime-main from bugfix/SMIME-437-FROM-2.1 to release/2.1.x
07f6c2fd (release/2.1.x) fix tab content for action view

So - what am I doing wrong? Or is this the expected behavior? We really need to develop two Releases (or even more) in parallel. Would love to use reckon ....

ajoberstar commented 5 years ago

I think this is a weakness of the current parallel branch handling. If you tried to develop a release/2.2.x branch, it would correctly skip 2.1.0 which is being developed elsewhere and give you 2.2.0, because they use the same scope to increment from the base 2.0.0 version. Since you want to do major, minor instead of minor, minor, it doesn't work.

Seems like a bug, though I'd have to think through how this could be resolved.

sdavids13 commented 5 years ago

For some reason Reckon doesn't seem to infer the correct version when using release branches. For example, I have a tag of 0.1.0, then created a branch: release/0.1.x but when reckoning the version on that branch it bumps the version to 0.2.0-dev.1 instead of the expected 0.1.1-dev.1. The old gradle-git and the nebula-release plugin seems to do the right thing. I am curious if I am missing something somehow, I haven't seen anything in the documentation to say if it is supported or not.

ajoberstar commented 5 years ago

@sdavids13 The old gradle-git plugin had a concept of branch patterns that would let you coerce/hint to the plugin that you have a particular normal version in mind for this branch. Currently, reckon doesn't look at branch name at all. There are some conceptual benefits to keeping it generic, but it makes it hard to handle this kind of use case.

If you wouldn't mind opening a separate issue, I think something tied to either branch names or you being able to provide hints of the version like -Dreckon.pattern=0.1.x (and some equivalent programmatic API might let people mix and match this without reckon needing to know the branch (though that's still an option too).

ajoberstar commented 5 years ago

@ctolkmit Finally taking a look at this, here's what I think is going on:

One of the big issues here is that I'm purely looking at commit history and not branch names (as mentioned above). This is partly because some CI systems don't preserve branch names properly at all times, and also it avoids having to know what your naming convention is.

An assumption reckon makes is that you have to have contiguous version numbers (e.g. you can't jump from 2.0.7 to 3.1.0 since it requires a major jump then a minor jump).

It might help to see your log with the --graph flag to provide a better picture of your history. If 3.0.0-rc.1 is in the history of release/3.1.x I could see some potential options for inferring this correctly. Otherwise, I think reckon wouldn't have any way to identify this without understanding branch names.

ajoberstar commented 2 years ago

I think the approach used to solve #180 (see #181 for description, released in 0.17.0-beta.1) will resolve many of the parallel version use cases. Not positive about this specific one, but would appreciate any feedback.