Prepare for 1.1.0 release

[jamesaoverton]

I'd like to make a ROBOT 1.1.0 release this week. As always, I'm paranoid about releasing something buggy. Can you give it a test drive? @cmungall @rctauber @balhoff @dougli1sqrd @simonjupp everyone?

Here's a JAR to test: https://build.berkeleybop.org/job/robot/141/artifact/bin/

Below are my draft release notes. I'm a little worried about the possible breaking change -- let me know if you have suggestions.

---

This release of ROBOT includes a large number of improvements and the new report command.

Changes:

• --collapse-import-closure option for merge: When true by default, all imports will be merged and all owl:import statements will be removed. Possible breaking change: In previous versions of ROBOT, owl:import statements were not removed. #275
• report command runs a series of quality control SPARQL queries over the input ontology and generates a TSV or YAML report file based on the results
• improved error messages, linking to ROBOT website #246
• global --catalog FILE option #274
• --check option for convert allows conversion of more OBO-format files
• --include-annotations for better control of annotations when merging #277

[cmungall]

I have been using master a lot and have not encountered any issues not reported in a ticket, but I haven't methodologically tested everything.

Do we want to address any issues first or freeze feature additions on master?

We could be making more use of either github projects or milestones here, we can start next release.

[beckyjackson]

Has there been any talk about a ROBOT mailing list for this sort of stuff?

[jamesaoverton]

A mailing list is a good idea.

[cmungall]

mailing list: I tend to favor groups.io these days - @nlharris did you manage to resolve whatever issues you were having with the godev one?

release: would be great to have this by ICBO, with updates to the osk docker containers. Can we go ahead and merge the two non-WIP PRs now, make 1.1.0-rc1? I can rustle up some testers.

Testing: moving forward this will be easier, as we have a big bank of ontologies in github that have reproducible robot workflows. Many of these are running of robot master, so we'd have heard of many bugs by now. As these adopt the new osk workflow they will be running from versioned docker instances, we could have a test workflow where we fork, spike in a new release, check travis. This could be automated (he says without a clear plan of exactly how this would work).

[jamesaoverton]

release: I plan to take https://github.com/ontodev/robot/commit/30a1113b0a8ab59ad243d188ad66f9102aecfe9b, bump the version to 1.1.0, and release it tomorrow on GitHub and Maven Central.

If anybody wants to test that in the next 15 hours or so, that would be great.

Then I will merge PRs #290 and #328 and call that a 1.2.0-alpha (or something) release on GitHub. So we'll have a stable and a development release available for ICBO.

[jamesaoverton]

• ROBOT 1.1.0 release: https://github.com/ontodev/robot/releases/tag/v1.1.0
• ROBOT 1.1.0 tag: https://github.com/ontodev/robot/tree/v1.1.0
• ROBOT 1.1.x branch (for fixes, if required): https://github.com/ontodev/robot/tree/v1.1.x
• Sonatype staging: https://oss.sonatype.org/content/groups/staging/org/obolibrary/robot/
• should be on Maven Central soon

[jamesaoverton]

• ROBOT 1.2.0-alpha-1 release: https://github.com/ontodev/robot/releases/tag/v1.2.0-alpha-1
• ROBOT 1.2.0-alpha-1 tag: https://github.com/ontodev/robot/tree/v1.2.0-alpha-1

I have not put this on Maven Central, and I'm not sure if I should. Opinions?

[cmungall]

I am fine with only releases going on mvncentral

I'm making a new odk (formerly osk) Dockerfile and pinning it to the 1.1.0 robot release (pulling jar from github rather than maven central)

[jamesaoverton]

Ok, agreed: Only production releases will go to Maven Central.