releaseTagPattern in SCMService does not match the tag pattern used in ReleasePlugin

[solidjb]

The pattern to determine the next tag version inSCMService is

private final def releaseTagPattern = ~/^(\S+)-REL-(\d+)$/

However the code in ReleasePlugin uses a slightly different pattern:

getSCMService().performTagging(getSCMService().getBranchName() + "-RELEASE-" + project.version, msg)

These two patterns should match. It would also be cool if that prefix could be configurable, with options like:

useSourceBranchInTag (would determine if you would put 'trunk-' at the beginning of the tag) tagTextPrefix (would give you a place to put text that you would want pre-pended to the version number in the tag name e.g. RELEASE-) tagTextSuffix (would give you a place to put text that you would want appended to the version number in the tag name e.g. -RELEASE)

These are just ideas, I can try and implement them if they sound ok to you.

[ari]

Thanks for finding the REL/RELEASE bug. Indeed it should be fixed. Although I don't like removing the branch name since that is important in svn to understand where the tag came from. Not important in git though...

Instead of adding a bunch of new flags to turn things on and off, what do you think about exposing the whole tag string builder via a closure? Then you get more flexibility and fewer options.

[solidjb]

Why is it important in SVN to know where a tag came from? We use SVN and that has never been relevant to us. Just trying to understand...

As far as a tag closure, that makes sense to me, and is definitely a more "groovy" way to do things. Would you have variables like project.ReleaseVersion available to you in this closure? If so, then that makes the most sense.

Thanks for your feedback on this also.

[ari]

Even with a weekly release cycle, sometimes you need feature branches which go for longer periods (for big features). We do that too. Then we are able to release:

featureRed-4.1M1

That's a milestone release for internal QA (and at some point for betas, etc) and you need to know that it wasn't cut from trunk when QA start reporting bugs against it.

[solidjb]

Interesting... I can see why in your workflow you would need to know the source branch, but it actually becomes troublesome in our workflow, as the only time we create a branch is to create bug fixes for the version of code running in production. Our flow now would be if 1.5 is the version in production, then we would create a branch named PRODFIX_1.5.1. If we have the source branch in our tag when we create a version, then that would create PRODFIX_1.5.1-RELEASE-1.5.1. Obviously we could change our procedure, but adding the ability to programatically determine the tag name seems like a valuable addition as some organization might want to vary the release tag lots of different ways...