Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Reconsider OSGi versioning

See original GitHub issue

All Flow projects at the moment use OSGi (Bundle-Version manifest tag) version of form 1.2.3. That does not guarantee bundle uniqueness if an OSGI container have pre-release and final bundle versions deployed simultaneously. In case of OSGi approach that may lead to hard-to-detect problems even in production systems. We may use versioning like 1.1.3.20180102 which should work much better. For OSGi versioning see https://bnd.bndtools.org/chapters/170-versioning.html, §9.2 see ${parsedVersion.osgiVersion} maven property

Issue Analytics

State:
Created 5 years ago
Comments:5 (5 by maintainers)

Top GitHub Comments

1reaction

plekucommented, Nov 2, 2018

Unlike falsely claimed here, everything is apparently working like it should and how has been done previously in the framework.

Only difference is now with snapshots, eg. 1.0-SNAPSHOT is released as

1.0.0.20181102 for Flow artifacts
1.0.0.SNAPSHOT for component Java integrations

This is fine. Final releases and prereleases work consistently everywhere, and the same as before in the Framework. If someone wants to mix snapshot and release/prerelease versions of the components in an OSGi environment, then we can revisit this.

0reactions

mehdi-vaadincommented, Oct 31, 2018

We should check the version sorting mechanism of OSGi to make sure that for example 1.2.0.0 is considered bigger than 1.2.0.SNAPSHOT.