Automated versioned builds: Only apply when src/ or libraries changes

[phillipjohnston]

Related to #90, prompted by discussion in #64:

One reason I can think of would be that non-code related items, such as README changes or infrastructure changes, should not generate a new release version. In that case, I would still fall back on having the nightly build be manual instead of automatic, but that also increases the friction of releases being made after PRs are merged - I'd have to remember to go and click the button, which is quite easy to do. I could also check whether or not changes have been made to src/ or libraries.

Explore this option.

[phillipjohnston]

Alternative, however, is to handle version numbering differently, since leveraging jenkins build number is really the more problematic part. Or we do need that intermediate develop-style approach, so merges to master will be properly incremental.

[phillipjohnston]

Another option is to keep the current strategy, monitor only for src/library changes, and use this plugin to discard aborted builds. Probably needs to be combined with this plugin to reset numbers to the current attempt.

[phillipjohnston]

The plugin for discarding aborted builds works great. The plugin to reset build number does not function in pipeline builds, instead requiring JobDSL.

[phillipjohnston]

Next build number can be reset with a pipeline library function!

[phillipjohnston]

Current conflict: build-history-manager deletion deletes everything but build.xml, which means that setting the next build number fails because a build exists. Investigating other options.

[hagaigold]

Is there a reason I'm missing that it would be superior to manually manage it?

this is only my preference- manually manage the version number over automatically increasing it.
but as you mention above:

since leveraging jenkins build number is really the more problematic part

if you wish to increment the version number automatically, why not also keep it in a JSON file (or header file) as part of the codebase? pushing it from Jenkins is very awkward to my mind.
I believe the version should come from the source and not externally. Then bumping it manually or automatically becomes just a CI implementation detail...

[hagaigold]

another argument (and maybe the strongest for my mind)- when you browse the code (or checkout old commit), you can not see what version are you looking at.

[phillipjohnston]

when you browse the code (or checkout old commit), you can not see what version are you looking at.

Just FYI, every release is tagged so you can always find out what version you're looking at with git describe --tags. This would be more convenient reading a version from a file, because git describe will tell you how many commits you are from that release, while the version in the file will not include.

This is not an argument against your suggestion, just thought you might like to know!