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 >
