As I explained here, I did update ImageJ-OMERO to use OMERO 5.5 a while ago. The work was waiting on the release of pom-scijava 28.0.0, which is now complete. So I’ve now gone ahead and pushed the OMERO 5.5 update to the master branch:
I have also promoted the imagej-omero dev version number to 1.0.0-5.5-SNAPSHOT. Reasons:
- To my knowledge, no major new development is currently planned for imagej-omero. We have the functionality we have, and the plan is to maintain it as-is—updating to version 1.x conveys that intent to preserve backwards compatibility.
- The -5.5 suffix clarifies to which version of OMERO a given release of ImageJ-OMERO is bound.
If a future release of OMERO breaks imagej-omero’s API compatibility, we can bump the imagej-omero major version digit.
If bug-fixes are needed to imagej-omero for a particular release of OMERO, we can bump the patch or minor digit of imagej-omero while preserving the OMERO version suffix—e.g., 1.0.0-5.5 1.0.1-5.5 for bug-fixes, or 1.0.0-5.5 1.1.0-5.5 for backwards-compatible new features.
I did not yet cut the 1.0.0-5.5 release of imagej-omero, because the Travis CI build is failing:
The failure is caused by an issue with test.imagej.net. I’ll investigate soon. Next steps:
- Restore the
- Ensure the Travis CI build passes, fixing any remaining issues
- Cut the 1.0.0-5.5 release of imagej-omero
- Update imagej-omero-legacy in a similar fashion and release it as well
- Upload the releases to the OMERO-5.5 update site (functionally they are unlikely to be different than what’s already uploaded there, but good to have the official releases being served)
- Add the OMERO-5.5 update site to the central list of ImageJ update sites
- Try upgrading to OMERO 5.6.
@j.burel Is OMERO 5.6 backwards compatible with 5.5? I’m assuming not since it’s not a patch release? Should I go ahead and create a separate OMERO-5.6 update site once I get to that point, then?