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
