Hi, I had some time to think on my ride home on the bike and I came to the conclusion that it does not make any sense to release the enhancer without any engines. We have to ensure that our supported engines are always working with the latest version of the enhancer and its API. So when we change the enhancer we will naturally change all engines that would get broken by this change.
I played around in Jira this afternoon and tried to figure out how to setup the components and release versions. I started to create components in Jira for each engine and release versions for each. But this approach is also just impractical. The issues are not separated for single engines and typically one issue requires changes at different places (enhancer core and engines). So my conclusion is that this will not work and I will undo my latest changes in Jira. We should not release the enhancer without any engines. Enhancer and engines should always be released together. This would make is also easier to understand which enhancer version is compatible with which engine versions. I think the engines should always have the same major version as the enhancer API. Enhancer API 1.x will work with engines 1.x, 2.x with 2.x and so on. But if we want to release the enhancer plus the engines, we have to release, e.g. the EntityHub, too. Some engines have dependencies to other components, so these need to be released first. I will check the dependencies. Best, - Fabian 2012/5/30 Tommaso Teofili <[email protected]>: > 2012/5/30 Fabian Christ <[email protected]> > >> 2012/5/30 Tommaso Teofili <[email protected]>: >> >> To conclude: I do not object with you suggestion. I only tried to >> >> point out that I believe you assumption that the parent POM will not >> >> change very often is not the case for a "dependency heavy" project >> >> like Apache Stanbol. If you do not have a problem with parent POM >> >> versions >20 than your proposal might still be OK. Otherwise I would >> >> suggest to use minor version upgrades for version changes of >> >> dependencies. >> >> >> > >> > I think that would make sense if don't change APIs, otherwise a major >> > version change is needed IMHO. >> >> The parent POM does not define any API. It just configures the >> dependencies. So to distinguish between major.minor does not make >> sense here if you want to express some degree of compatibility. The >> next version is just different from the one before - simple counter >> IMHO. >> > > right, but if it might happen that dependency version change would require > adapting our classes/APIs, that was my only concern with minor/major > version changing. > Tommaso > > >> >> -- >> Fabian >> http://twitter.com/fctwitt >> -- Fabian http://twitter.com/fctwitt
