Closed jimmidyson closed 8 years ago
@rhuss Thinking about it, I'd like to get this in - it doesn't change the branch/tag model but simplifies changing major/minor versions for next tags. Are you happy to merge this & discuss how we do the commits later?
I'm going to merge this & try it out - if it fails then I will revert.
Im a little worried about this if I'm honest as this is a core change that will affect how every fabric8 Java project is released and I'm not totally clear of the motivation. I.e is this a fix or an improvement to something? It may not be totally complete but we tried a few things to get to this point and it's been working for over 6 months. If there's no immediate reason to change the process it might be worth holding off until we have time to understand everything, when I'm around to help maybe.
Alternatively if you guys want to go on ahead please don't break things ;)
These are a couple of things to keep in mind..
@rawlingsj the change in this PR was an improvement, it doest not change how versions are build. It simply says, that, when the e.g. the snapshot version in the pom.xml e.g. 3.2-SNAPSHOT is larger than the tag e.g. v3.1.12, then the version should be bumped up to v3.2.0. Same for the major version.
So its an easy, non-intrusive way for bumping up major and minor version manually while letting the patch level be managed by fabric8 CD as it is now.
All the other comments were only brainstorming and trying to list some pro- and cons of various approaches.
Ok cool that makes sense. All sounds good.
Thanks for explaining @rhuss. It certainly should work like that...
@rhuss @rawlingsj What do you think of this? This should mean you can e.g. bump the minor version in your SNAPSHOT version & next tag will use that minor version. For example, say you're using 1.3-SNAPSHOT & tags are being released 1.3.1, 1.3.2, 1.3.3, etc. You want to bump minor version, you should be able to just bump pom version to 1.4-SNAPSHOT & next release will be 1.4.0, then 1.4.1, etc. Same for major version.
Hard to test, but if you're happy with it I'd like to try it for kubernetes-client release (which was the actual use case for this).