Hi, Currently the whole Oak source tree is synchronously versioned. Which is great for Oak and its releases, but problematic downstream. I assume this has been discussed before, and hope it can be discussed again ?
------ If it can, here is some supporting evidence, using Sling as an example.If it cant be discussed and the case is closed, the please ignore this thread. Currently: When a version of Sling depends on Oak 1.6, 1.4 or 1.2 , and needs a feature or an API from Oak 1.8-SNAPSHOT, that feature or API must be backported and released to 1.6, 1.4 or 1.2, but probably all versions back to the one desired. With OSGi this is not necessary since OSGi works on the version of the package, not the bundle. The bundle from Oak 1.6, 1.4 or 1.2 will all have to have the same package version, which they do when an API change is made. This adds a second constraint. Changes to all the branches probably have to be made in the same sequence to ensure that the package versions remain in sync. Not doing so will create many problems downstream eventually. If not strictly enforced there will be the same version of a package, from different bundles, containing different APIs. More coordination between pending pull requests will be required to ensure that changes get made in the right order. With one or two stable branches, that is manageable, with more it may not be. Once a package it released, it may be very hard to untangle a conflict. Alternatively: If a API bundle is stable, and has not changed since version 1.2, then the same API bundle is used through all versions. When that API bundle has a change, it is released and the new version can be used, if required by all versions of Oak, Sling and everything downstream. Only the API bundle needs to be released, nothing else. APIs should be compatible within a well defined range, enforced by the OSGi container, builds, unit tests and integration tests. That mean less blocking downstream and from an Oak pov, less backporting work. When the bundle is an implementation bundle, its even simpler. No wholescale release of Oak is required, just the bundle integrated with each release. Again less work for Oak. Obviously bundles remain the release unit, and the build must include OSGi based integration tests that validate a release is viable. I am not saying all the problems are solved by independent bundle versioning. There will be new problems. Perhaps, there would be less work for Oak, and more flexibility downstream with independent versioning. wdyt? Best Regards Ian
