Make a proper release of 0.6.0

Question

Make a proper release of 0.6.0

Closed this issue 11 years ago · 18 comments

So far, we only have releases 20100908, 20111128 and 20120621. The pom.xml suggests that we are in the 0.6.1 release cycle now, but 0.6.0 was never formally released, nor is there a tag indicating what revision that should have been.

Unfortunately, legacy-imglib1 depends on mpicbg so if we ever want to hope to have a reproducible build of a release of the former, we need to have the same for the latter first.

Answer 1 · 2014-03-19T20:37:19.000Z

@axtimwalde Ping?

Answer 2 · 2014-03-22T23:06:18.000Z

@axtimwalde please reconsider your silence. It is a road block, and as I stated in fiji/fiji#44, this problem is actually much older than this ticket. It is a bit distressing to be blocked that long.

Answer 3 · 2014-03-22T23:07:08.000Z

Alternatively, I will of course take matters into my hands (as I always do, to keep Fiji working, even if the workarounds are ugly -- if necessary).

Answer 4 · 2014-03-24T01:32:26.000Z

@dscho Maybe @axtimwalde doesn't watch this repository? Did you email him?

Answer 5 · 2014-03-24T13:38:04.000Z

@axtimwalde should get notifications everytime his name is mentioned on GitHub. But sure, I will mail him.

Answer 6 · 2014-03-24T14:27:32.000Z

Thanks for the e-mail. I auto-deleted GitHub messages for the last couple of days because I git auto-subscribed to an overwhelming number of messages that I didn't have time to process. Sorry.
In defense of why there is no release version of 0.6.0: It wasn't necessary nor sensible at the time. Today, it is hard to identify the point in time when mpicbg was at 0.6.0 and therefore I suggest that we label the current master as 0.6.1 release and set this as the first confirmed release version ever. Would that work?

Answer 7 · 2014-03-24T14:34:06.000Z

I suggest that we label the current master as 0.6.1 release and set this as the first confirmed release version ever. Would that work?

Yes. If you update to the pom-scijava parent to the current version and push to master with that release version set in the pom.xml file, the Jenkins job will deploy it to the ImageJ Maven repository.

Answer 8 · 2014-03-24T15:02:20.000Z

What is the current version of pom-scijava?

Answer 9 · 2014-03-24T15:04:43.000Z

@axtimwalde: According to Maven Central, it is 1.153 as of this writing.

Answer 10 · 2014-03-24T15:12:20.000Z

Thanks. I just updated the pom.xmls accordingly, tagged them and pushed to master. Does that resolve the issue and unblocks all roads?

Answer 11 · 2014-03-24T15:21:20.000Z

@ctrueden: I see a problem arrising when reading your commit message in

a548d2f

Is that issue resolved in 1.153?

Answer 12 · 2014-03-24T15:52:04.000Z

@axtimwalde: Yes, no worries, the problem with javadoc described there was resolved again by 1.127. Using 1.153 for the parent is just fine.

The problem with Jenkins today was because there is now more than one commit on master with the same release version 0.6.1 of MPICBG. You can only deploy each release version once.

First you did: d14548d
And then you did: 732885c

The latter without resetting the version of mpicbg back to a SNAPSHOT (in this case: 0.6.2-SNAPSHOT). It is very easy to forget to do this, which is why we usually use the release-version.sh script instead—it takes care of all of that for you. But @dscho has opted to go with a "commit Fiji plugins at release versions directly to master" approach. The advantage being that Jenkins will automagically make the release for you, but the downside being that you have to remember to switch to the next SNAPSHOT again manually. I guess we could teach Jenkins to do that last part for you automatically too, but we haven't done that yet. @dscho, thoughts?

Answer 13 · 2014-03-24T16:29:06.000Z

Thanks for explaining. I didn't know from where release-version.sh derives the version number and guessed it would take it from a tag. What am I supposed to do next? Am I supposed to push anything to Fiji or TrakEM2?

Answer 14 · 2014-03-24T17:03:19.000Z

@axtimwalde: The version for release-version.sh is given as the (sole) argument to the script. But you need to have deploy permission to the ImageJ Maven repository in order to use it. As I said above, I think @dscho's preference is to let Jenkins do it for you.

So, could you please push a very simple change to master? Just bump the <version>0.6.1</version> to <version>0.6.2-SNAPSHOT</version>. That way, subsequent commits will not be "competing" for the same release version, which is supposed to be unique. And we will fix the deployment of 0.6.1 to match 732885c.

To make a release in the future, push a commit bumping to e.g. <version>0.6.2</version>, and then after Jenkins builds, push a second commit bumping to <version>0.6.3-SNAPSHOT</version>. (And if you add new features rather than only bug-fixes, I'd suggest using <version>0.7.0</version> instead followed by <version>0.7.1-SNAPSHOT</version> and so forth. This is the SemVer way.)

Answer 15 · 2014-03-24T18:40:17.000Z

Yes, I fear that there is no substitute, not even here, for switching to a SNAPSHOT version right after deploying a release. It also makes for development discipline, which is why I actually like it.

Answer 16 · 2014-03-25T15:22:02.000Z

Ok, done. All pom.xmls are at 0.6.2-SNAPSHOT. Thanks!

Answer 17 · 2014-03-25T16:23:37.000Z

Thank you @axtimwalde. As you can see here, it compiled, ran all unit tests successfully and deployed the new snapshot to the ImageJ Maven repository.

Hence this ticket is addressed, at long last!

Answer 18 · 2014-03-25T17:22:31.000Z

@axtimwalde there is just one thing missing: a tag. For your convenience, I made one. Please call this:

git fetch https://github.com/dscho/mpicbg 0.6.1
git push origin 0.6.1