search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.15k stars 592 forks source link

Use ranges that restrict minor version increments instead of micro version #16134

Open tjwatson opened 3 years ago

tjwatson commented 3 years ago

The build of liberty .feature files currently uses a bundle version range of [X.Y.0, X.Y.200) where X and Y are the major and minor version for the built bundle. The use of 200 for the micro version ceiling is a bit arbitrary and will need to change once our monotonically increasing micro version hits 200. I suggest we drop the 200 micro version from our ranges. Instead use ranges of the form [X.Y, X.Y+1). For example, instead of [1.1, 1.1.200) we should use [1.1,1.2)

If this is done for the .feature processing then we should also update the hardcoded ranges that are included in the .bnd files for our utilities as well as the kernel.mf

tevans78 commented 3 years ago

Does this mean that if someone intentionally put [1.3, 1.7) in their feature file, we would change that to [1.3, 1.8) in the manifest?

tjwatson commented 3 years ago

Do you have examples where a range is hardcoded in a .feature file? I've only found this very strange declaration in /com.ibm.websphere.appserver.features/visibility/public/openidConnectServer-1.0/com.ibm.websphere.appserver.openidConnectServer-1.0.feature:

Subsystem-Endpoint-Content: com.ibm.ws.security.openidconnect.server; version="[1.0.0,1.0.200)"

I've no idea what Subsystem-Endpoint-Content is used for. But to answer your question. If someone has put a hardcoded range anywhere I would only suggest modifying it if it was restricting on the micro-version. If it already is restricting on the minor-version then I would leave it as-is.

If your case instead had [1.3, 1.7.200) then I suggest it should be [1.3, 1.8) instead.

tevans78 commented 3 years ago

It was a purely theoretical example. I think you're saying that we would always round a micro version up to the next minor version? That sounds OK. If we can't find any other valid uses of a range within a feature file then maybe we should restrict it further somehow to prevent mistakes?

tjwatson commented 3 years ago

Feature versions should be generated by the build with .feature files. The problematic cases are kernelCore-1.0.mf feature which isn't build by a .feature file and the utility JAR manifests that use Require-Bundle. For the utility JARs it comes from the .bnd file. I suppose we could enhance the build for these. Not sure what the effort is to do that or if it would be worth it given that developing new utility JARs is likely to be rare.