OK I just looked up and found this from https://confluence.atlassian.com/display/GH/Tutorial+-+Tracking+a+Kanban+Team which seems fairly standard:-
Kanban is a methodology that constrains the amount of work that can be > assigned to a particular workflow state at any one time. This helps teams > to optimise their lead time (or cycle time) — that is, the average time > taken to complete a task. > Many agile development teams find that Kanban is particularly well suited > to bugfix or maintenance releases, *where incoming tasks are triaged and > then actioned according to their priority. As soon as there are enough > completed tasks to constitute significant value, a minor version is created > and released. > *Devops teams, or agile delivery teams, often use Kanban. These teams set > a definition of done that includes the delivery of value to the customer. My underscore. In practice what happens is that releases are planned this way. After all the whole idea is release cycles. What I see is that here there are remote developers and Rupert is the 'scrum manager' i.e. responsible for release management. You might find it helpful to plan this out beforehand with an online tool? I think there are some free to use for open source. It may not be overkill. Then the issue of assessing *significant value* would be discussed instead of left to the developer on their own - what ever the agreed criteria. Adam On 24 November 2012 12:09, Reto Bachmann-Gmür <[email protected]> wrote: > Hi Rupert, > > So assuming a module is in trunk at version 3.4.1-SNAPSHOT and I make an > incompatible change, to what should I change the version number to? Does > the degree of incompatibility makes a difference: > - A change that affects clients of the interface > - A change that affects subclasses (when knowing that there are such > subclasses/not knowing) > - A change in the behaviour (documented behaviour/undocumented side effect) > > Cheers, > Reto > > On Sat, Nov 24, 2012 at 12:34 PM, Rupert Westenthaler < > [email protected]> wrote: > > > 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 > > >
