OSGi versions of packages did not change since 1.1

[pdudits]

Since release 1.1, the exported version of main package is 1.1, and versions of subpackages is 1.0.1.

This clearly does not reflect the changes in the API since May 2018.

The per-package versioning was introduced in #81, but then the version of every package needs to be carefully reviewed before every release, which is unfortunately not happening.

[andymc12]

@pdudits - thanks for raising this issue. I definitely dropped the ball on this one.

Can you take a look at my pull request (#179) to make sure it is what you would expect?

Thanks again!

[pdudits]

This is my first encounter with per-package versioning, so I'm not sure what to expect. But it is confusing to me.

In my experience, clients (and tooling) usually import packages with version ranges (so usual import for API 1.2.1 would be [1.2,2.0)). What problem does per-package versioning solve?

From API user's point of view, it just looks inconsistent. For example, javadoc of ClientHeaderParam says @since 1.2, whereas the exported version of package is 1.1 (after the PR is merged). And this leads to lots of false alarms when diagnosing OSGi issues -- just like I suspected, that I'm importing wrong REST client, when in fact my real issue was #178.

[andymc12]

@pdudits I agree it can be confusing, but the idea of semantic version has merit. And if the Java EE community would follow the same rules, then I think it would've avoided the problem you are seeing in #178. Because the CDI spec didn't make any breaking changes to consumers (only to implementors), it really should have called itself 1.3 instead of 2.0 (or at least updated the package versions in such a way).

In MP Rest Client 1.2, we only made minor changes to the API packages (changes that break implementors, but not consumers), so OSGi bundles that were generated by tools like BND should continue to work just fine - unless you are implementing the Rest Client APIs.

Here is a brief explanation of semantic versioning used in OSGi:
https://enroute.osgi.org/FAQ/210-semantic_versioning.html

Hope this helps - and thanks again for raising this issue - I've made it a note in my personal release process - and I'll look into the overall MicroProfile project release process to see if I can make a note to update OSGi versions there too.

[kenfinnigan]

@andymc12 this is done right?

[andymc12]

@kenfinnigan yes - I updated it for master (1.3) and the 1.2.X-service branch. We should probably publish a 1.2.2 release that includes these changes.

[kenfinnigan]

Do we need a 1.2.2 of 1.3 will be out shortly?

…

Sent from my iPhone

On May 7, 2019, at 11:01, Andy McCright ***@***.***> wrote: @kenfinnigan yes - I updated it for master (1.3) and the 1.2.X-service branch. We should probably publish a 1.2.2 release that includes these changes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[andymc12]

@pdudits do you have an opinion on whether a 1.2.2 release is useful? We should be releasing 1.3 later this week - and that has the correct OSGi package versions. But I understand that some vendors may be slower to adopt the 1.3 release and may want this fix in the 1.2 stream. In that case, I would be fine with publishing a 1.2.2 release.

[pdudits]

@andymc12 we surely want to ship updated rest client in release coming up in next weeks. We might not have the capacity to add features of 1.3 in it. So yes, I think a maintenance release would be good.

[Emily-Jiang]

To prevent this from happening in the future, I have added the bnd versioning plugin. I have done for some projects already. I will get all projects updated soon.