0

I have a Python script that lives in my CI pipeline that is responsible for publishing branches and tags, publishing AAR's to our Maven Artifactory, uploading Javadoc, etc.

We used to follow a modified version of Git Flow where we would publish off of either a "support/" branch (for Long Term Support of a Minor Product Version, such as 'support/5.10') or a "release/" branch (for release regression testing.

My script largely relied upon the Git Branch name in order to determine Major/Minor/Patch version bumps.

Now, we are dropping the support branches and moving to a more vanilla Git Flow workflow where we will do HotFixes solely off of Master (well, we will still have release branches, but that problem is solved...)

However, I can't figure out a way to safely determine the patch version off of the Master branch, as it obviously has no identifying characteristics in it's name that we can scrub (I always felt a bit uneasy about the method we are using, but... it worked).

I can access the tags and always bump the highest one, but that's sketchy.

I can input a target version, but that gets in the way of CI and would force us to run this script manually.

Any other thoughts on how to approach this? Anyone already solved this problem?

Improve this question
6
  • Can you inspect the software version? If you're using maven, you can parse the pom file and figure out the version.
    – Samuel
    Aug 8, 2017 at 21:36
  • "I can access the tags and always bump the highest one, but that's sketchy." - What's sketchy about it?
    – 8bittree
    Aug 8, 2017 at 21:39
  • 1
    please don't cross-post: stackoverflow.com/questions/45578001/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..."
    – gnat
    Aug 9, 2017 at 7:06
  • Ah, I wasn't aware that was frowned upon...
    – jesses.co.tt
    Aug 9, 2017 at 14:09
  • 1
    Any reason not to just use 'git describe'? This gives you the last tag plus the number of commits since the tag, so uniquely identifies the specific commit you are building from.
    – Sean Burton
    Nov 7, 2017 at 12:54

1 Answer 1

Reset to default
1

A practice that I have seen used successfully was to:

  1. Major/Minor releases, i.e.: n.0.0 or n.m.0 are triggered by pushing a tag, possibly generated by a python script, for the release number with a pre-commit hook to:

    1. Ensure that the correct pattern was followed &
    2. Ensure that it was the next incremental major or minor release,
    3. Ensure that there were no test failures & no changes since the last development push.
  2. Changes pushed to Master, on successful completion of the tests, caused automatic creation & push of a tag that was the next incremental patch version, i.e. x in m.n.x - since all of the tags were generate there was no problem parsing the tags
  3. That tag was automatically built & deployed.

Note that the script for tagging would prompt the user for:

  • Major or Minor Release?
  • Pre-Release Alpha, Beta or Final?

Any pre-releases were "released" into a preview area for testers &/or test clients to access.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.