Allow the Bump-POM-SciJava Jenkins job to bump preemptively

[dscho]

When, say, scijava-common is released in a new version, we usually bump scijava-common's version first, then pom-scijava's (after adjusting the scijava-common.version property).

This poses the following problem: the new pom-scijava version references the new scijava-common version in its <properties> section, but the same scijava-common version has the previous pom-scijava version as parent.

I propose to allow the Jenkins job to adjust the scijava-common.version property in pom-scijava first (i.e. before it is valid), deploy pom-scijava, increase both the scijava-common version as well as the pom-scijava parent version in scijava-common's pom.xml and then deploy scijava-common, too.

We could easily adjust the Jenkins job we use to bump the pom-scijava version already by adding another parameter that allows us to specify which artifact (or artifact's) to release. The user would have to specify the new version as well, and the Jenkins job would then have to call release-version.sh, too, making sure that the children (i.e. the projects whose parent version needs to be bumped) are handled according to the order implicitly given by the project dependencies.

@ctrueden @hinerm what do you think?

[ctrueden]

The bump-versions-in-pom.sh script was retired earlier this year, along with the Bump-POM-SciJava Jenkins job. See also #4, #5 and #8.

This poses the following problem: the new pom-scijava version references the new scijava-common version in its <properties> section, but the same scijava-common version has the previous pom-scijava version as parent.

I just want to clarify here, in case anyone comes across this issue, that the above situation is not actually a problem in any way I can see. A project cannot depend on itself (neither directly nor transitively), and the version properties are not generally used for anything else besides dependency version resolution.