Hi, I have just created a new Jenkins job for the release-0.12 branch to keep track of all changes there. This build uses JDK 1.6 - is this okay or should we use 1.7?
https://builds.apache.org/view/S-Z/view/Stanbol/job/stanbol-0.12-1.6/ Best, - Fabian 2013/12/6 Rupert Westenthaler <rupert.westentha...@gmail.com>: > Hi all > > Some more throughs about versioning: > > Out of a user perspective it is really nice if all artifacts of a > project do use the same version. However OSGI puts a lot of semantic > into versioning [1] [2] so increasing lets say the version of the > Enhancer from 0.11.0 to 0.12.0 indicated that there were some methods > added to the Enhancer APIs and so all implementing modules need to be > adapted. > > However there is not need to keep Maven versions in sync with the OSGI > versions. This is only the case because we currently use > `version=${project.version}` in the Export-Package declaration. Here > an example: > > <Export-Package> > org.apache.stanbol.enhancer.servicesapi; version=${project.version} > </Export-Package> > > Generally OSGI versions and Maven versions do anyway not fit very > well, as Maven versions whole modules while OSGI is based on packages. > > There are also some example of other modules that use different > version for Maven and OSGI. `commons-io:commons-ii:2.4` export [3] > packages that where already present in version 1.4 with the OSGI > version `version=1.4.9999` and only newly added packages with > `version=${project.version}`. This allows to use - the fully backward > compatible - 2.+ versions of the module with OSGI components that > import a version 1.+ of those packages. > > > So my suggestion would be to: > > * update everything to 0.12.0 in the release-0.12 branch > * keep everything with 1.0.0 in the trunk > * add maven properties with the version of interfaces to the parent > pom.xml files of Stanbol components (enhancer, entityhub, > commons.solr, ...) and use those instead of the project.version for > exporting interfaces. > > Those properties will allow to decouple maven versions with interface > version what should allow use to have both: (a) correct semantic > versioning for OSGI and (b) consistent Maven module versions that are > intuitive for Stanbol users. > > WDYT > Rupert > > > > > [1] http://www.aqute.biz/Bnd/Versioning > [2] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > [3] http://search.maven.org/#artifactdetails|commons-io|commons-io|2.4|jar > > On Fri, Dec 6, 2013 at 8:09 AM, Fabian Christ > <christ.fab...@googlemail.com> wrote: >> Hi, >> >> first a big sorry that this release got delayed so much. I wanted to have >> it out in the summer but different responsibilities made it hard for me to >> find enough time. >> >> So +1 for the release and thanks for pushing it. I will try to be more >> present and help to finally cut the release. >> >> Best, >> - Fabian >> Am 05.12.2013 20:51 schrieb "Enrico Daga" <enricod...@gmail.com>: >> >>> Hi Rupert, >>> thank you for boosting this. >>> >>> >>> On 5 December 2013 06:39, Rupert Westenthaler < >>> rupert.westentha...@gmail.com >>> > wrote: >>> >>> > Hi all, >>> > >>> > In the last few weeks there was not much progress on this.Starting >>> > with next week I should have time to work on that and hopefully get it >>> > out before Christmas! >>> > >>> > But before continuing I would like to ask for opinions on some >>> > decisions we need to take: >>> > >>> > 1. Module Versions: Currently different Stanbol Component do use >>> > different module versions: Commons: 0.12.0-SNAPSHOT; Enhancer: >>> > 0.11.0-SNAPSHOT; Enhancement Engines: 0.10.1-SNAPSHOT; Entityhub: >>> > 0.12.0-SNAPSHOT; all others components: 0.11.0-SNAPSHOT and finally >>> > all launchers and Bundlelists use 0.10.0-SNAPSHOT >>> > >>> > IMO we should update all those versions to 0.12.0 before the release. >>> > Even that this will require to manually set the OSGI version ranges >>> > for a lot of modules. >>> > >>> +1 to have all in the same major and intermediate versions. >>> >>> >>> > A light weight variant would be to only update the version numbers of >>> > the bundle lists and launchers and keep the current version numbers >>> > for all the other modules. >>> > >>> > 2. Add release-able Launchers: As most will know, we can not make >>> > binary releases of the current launchers, as they would include >>> > artifacts that are not compatible with the ASL (e..g the OpenNLP Model >>> > files). Because of that I would suggest to add Launchers that do not >>> > include such modules (meaning that they do not include a default >>> > configuration) and provide binary releases of Stanbol Launchers with >>> > the 0.12.0 release. >>> > >>> Make sense to me >>> >>> > >>> > 3. IMO we should keep the 0.12.0 branch active even after a release >>> > and back port compatible features and bug fixes. This is mainly >>> > because there will be several major changes in the trunk version and >>> > so it will mostly be good to provide fixes and improvements for users >>> > that require a more stable version. >>> > >>> Big +1 >>> >>> I strongly think that having an active branch from the released version to >>> work on bugfixes (towards minor releases, X.X.*) is the right way of doing >>> it. >>> We use the trunk to work on the next Major release (we are working on 1.0.0 >>> there). >>> About the versioning policy, we should definitely decide one. >>> My opinion is that all artifacts should have the same major and >>> intermediate version, and we should keep the minor version to change when >>> this make sense. But others may have better ideas. >>> >>> my 2 cents >>> >>> Enrico >>> >>> >>> > I have done this already for a lot of uIssues in the last few weeks >>> > and IMO the overhead of doing so is reasonable. >>> > >>> > 4. Set up a Jenkins build for the 0.12.0 branch: As this is considered >>> > the "stable" version it would be good to have Jenkins builds for this. >>> > >>> > best >>> > Rupert >>> > >>> > -- >>> > | Rupert Westenthaler rupert.westentha...@gmail.com >>> > | Bodenlehenstraße 11 ++43-699-11108907 >>> > | A-5500 Bischofshofen >>> > >>> >>> >>> >>> -- >>> Enrico Daga >>> >>> -- >>> http://www.enridaga.net >>> skype: enri-pan >>> > > > > -- > | Rupert Westenthaler rupert.westentha...@gmail.com > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen -- Fabian http://twitter.com/fctwitt
