Hi, Ok, I didn't follow that process for the changes in web.base. Also I'm not sure if this sin't going a bit too far, basically this guarantees that no matter at which time you take a trunk snapshot version you will have a compatible release at some point. It might have been justified to release web.base before the changes (depending on how man bugs were fixed since the last reelase) but now there should be another change that affects the location of the static files so again an incompatible change, I think that doing an intermediate relase (templates at new location static files at old location) would be an exaggeration.
Cheers Reto On Mon, Nov 26, 2012 at 1:09 PM, Fabian Christ <[email protected] > wrote: > 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 >
