Hi, making incompatible changes should trigger a process like:
1) announce what will break 2) make a release plan to ensure that all changes before this break got released 3) do the releases and increase the major/minor version number 4) make the breaking change We should ensure for the community that we do not break anything without releasing the status quo before. This gives people a chance to stick we the old version. And yes - we more and more urgently need a 1.0.0 release as a fix point to get this process running. Best, - Fabian 2012/11/24 Rupert Westenthaler <[email protected]> > Hi Reto, > > if you make incompatible changes to an module than you need to adapt > all dependent modules and update the dependency of them to the current > version. > > Normally the > > -provider-policy : ${range;[==,=+)} > -consumer-policy : ${range;[==,+)} > > would ensure that release Bundles are not affected by that. This is > also the reason why for an incompatible API change a major version > increase is required. However for pre 1.0.0 versions this is not the > case. > > best > Rupert > > On Fri, Nov 23, 2012 at 11:10 AM, Reto Bachmann-Gmür <[email protected]> > wrote: > > Hi, > > > > The concrete problem: I've made changes to the WebFragment interface (in > > org.apache.stanbol.commons.web.base). The classes implementing it no > longer > > compile if they have proper @Override annotations. Packages which used to > > implement the old version should remove the method and move the templates > > to another location. > > > > At runtime implementation of the old interface still work except that the > > method is never invoked and the templates are looked up in the new > > location. I've moved the templates to the new location in all modules and > > I've removed the method in those modules dependeing on the trunk version. > > The other modules are now in the state that they work only with the trunk > > launchers but compile only with the dependency to the old comms.web.base. > > If developer update the dependency version they'll have to find out why > it > > fails and what adaptations are needed. > > > > I think it would be much more efficient if the one that changes an > > interface also changes all dependencies in trunk to compile with the new > > version. Of course one could just update the modules depending on the > > updated one to use the latest version. Howver I think it would be more > > consistent to keep the reactor modules to depend on the latest versions, > > this can be done running and needs no change to depenedency management: > > > > mvn org.codehaus.mojo:versions-maven-plugin:1.3.1:use-latest-versions > > "-Dincludes=org.apache.stanbol:*:*:*" -DallowSnapshots=true > > -DexcludeReactor=false > > > > For the following modules we have other modules depending of older > versions > > of them: > > > > org.apache.stanbol.commons.jsonld > > org.apache.stanbol.commons.solr.core > > org.apache.stanbol.commons.stanboltools.datafileprovider > > org.apache.stanbol.commons.stanboltools.offline > > org.apache.stanbol.commons.web.base > > org.apache.stanbol.entityhub.core > > org.apache.stanbol.entityhub.model.clerezza > > org.apache.stanbol.entityhub.servicesapi > > org.apache.stanbol.entityhub.yard.solr > > > > Given that in the launchers the reactor build they have to be compatible > > with the latest versions anyway this seems inconsistent to me. > > > > For now I'll just update the modules to depend on the latest version of > > org.apache.stanbol.commons.web.base. > > > > Cheers, > > Reto > > > > > > > > > > On Fri, Nov 23, 2012 at 9:15 AM, Fabian Christ < > [email protected] > >> wrote: > > > >> Hi, > >> > >> is there any concrete problem with this approach? I would like to live > with > >> it at least for some releases and then decide upon our experience if it > >> fits. Otherwise it is just a meta-discussion. I see pros and cons on > each > >> side. > >> > >> Let's do a few releases and collect some evidence ;) > >> > >> > >> 2012/11/22 Reto Bachmann-Gmür <[email protected]> > >> > >> > I agree that if integration offer full coverage the will fail when a > >> > compatibility breaking change is introduced. However the advantage of > >> > statically typed languages is that you can detect this problems > already > >> at > >> > compile time. > >> > > >> > The two arguments you mention package split and interaction with host > >> > environment are in fact arguments for having all modules depend on the > >> same > >> > versions of their dependencies. As in the trunk launchers we use the > >> trunk > >> > versions these modules should also depend exclusively of the trunk > >> versions > >> > of other stanbol modules. Embedding is an import usecase that should > be > >> > supported, the easiest way to address it is to have just one version > of > >> the > >> > bundles and consistent dependencies. Backward compatibility (e.g. that > >> > somebody wants to use an old version of an engine with a new enhancer) > >> > seems less important and to provide this the current approach of > having > >> > engines compile but then fail at runtime doesn't seem a good approach > >> > anyway. > >> > > >> > Cheers, > >> > Reto > >> > > >> > On Wed, Nov 21, 2012 at 11:25 PM, Rupert Westenthaler < > >> > [email protected]> wrote: > >> > > >> > > > But I think they should nevertheless be kept up to date as > >> > > > otherwise we have no compile time check that the module will > indeed > >> > work > >> > > in > >> > > > the trunk version of the launcher. So I think we should regularly > >> run a > >> > > > >> > > UnitTest are executed using compile time dependencies > >> > > Integration test do check the runtime dependencies. > >> > > > >> > > So I do not see a problem with that. > >> > > > >> > > In addition one has to consider that the OSGI dependency management > is > >> > > anyway different from the maven one. > >> > > > >> > > To give two examples (for details have a look at the Semantic > >> > > Versioning Whitepaper [1]) > >> > > > >> > > 1. consumer and provider policy: Stanbol uses (since STANBOL-774) > >> > > > >> > > -provider-policy : ${range;[==,=+)} > >> > > -consumer-policy : ${range;[==,+)} > >> > > > >> > > That means that by default dependencies do use a version range of > >> > > [==,+). However this is not feasible for imported packages that are > >> > > implemented by an module, as minor versions may e.g. extend an > >> > > interface by an additional method. So for such cases the import > needs > >> > > to be marked with the provider-policy to ensure [==,=+). > >> > > > >> > > 2. Dependency management in maven is on module level where for OSGI > >> > > uses a package level granularity. > >> > > > >> > > Depending on the latest version undermines version ranges > (especially > >> > > for consumer-policy dependencies) - [==,=+) where the left side is > the > >> > > most current version means basically that there is no version range > at > >> > > all. > >> > > > >> > > - - - > >> > > > >> > > While such things are not really visible as long as you run > everything > >> > > within the OSGI environment it starts really to hurt as soon as you > >> > > want to access services form outside of OSGI (e.g. when you run > >> > > Stanbol in an embedded OSGI environment). In such settings one needs > >> > > to expose all packages of used interfaces via the system bundle and > >> > > therefore you do not have the possibility to use different versions > of > >> > > the same class. > >> > > > >> > > But also within OSGI there are some disadvantages one might > encounter. > >> > > One example is a fragmentation of the service registry (basically a > >> > > bundle may not use a service, because it's version of the Interface > >> > > was loaded using a different classloader as the version of the > >> > > Interface provided by the Service). If that happens ServiceTracker > >> > > will not get notified for available services - because they would > not > >> > > be compatible. Debugging that is not fun and solving such issues is > >> > > only possible by fixing version ranges. > >> > > > >> > > I agree that out of an maven and build perspective this might look > >> > > like a bad choice, but from the OSGI perspective it is exactly how > it > >> > > should be done. > >> > > > >> > > I think the version number confusion of sling is caused by the fact > >> > > the every single module can have totally different versions. I think > >> > > in Stanbol this can be easily avoided by ensuring that all modules > of > >> > > a Stanbol component (enhancer, entityhub, ... ) are all within > >> > > [==,=+). For the commons stuff we could use the same rule but one > >> > > level below (e.g. that all commons.solr modules are within [==,=+)) > >> > > > >> > > best > >> > > Rupert > >> > > > >> > > [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > >> > > > >> > > -- > >> > > | Rupert Westenthaler [email protected] > >> > > | Bodenlehenstraße 11 ++43-699-11108907 > >> > > | A-5500 Bischofshofen > >> > > > >> > > >> > >> > >> > >> -- > >> Fabian > >> http://twitter.com/fctwitt > >> > > > > -- > | Rupert Westenthaler [email protected] > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen > -- Fabian http://twitter.com/fctwitt
