Re: [incubator-taverna-engine] Generally tidy up the code. (#1)

[Stian Soiland-Reyes <st...@apache.org>]

What is your suggested change to the version numbers?

I've just committed 1-incubating-SNAPSHOT as the new version number of the
Maven parent.


The line of thought I have followed - which I would love your views on:

* Each reposisitory have their own versioning

* All version numbers follow Semantic Versioning 2.0.0
http://semver.org/spec/v2.0.0.html -- this is used by OSGi to check
compatibility.

* All submodules have the same version as the top pom.xml of the repository
(until a later point point where semantic versioning/OSGi says otherwise)

* All version numbers end in -incubating-SNAPSHOT on master.

* The SNAPSHOT version is the next one that would be released. So if
2.7.2-incubating was released, the SNAPSHOT number should now be
2.7.3-incubating-SNAPSHOT or 2.8.0-incubating-SNAPSHOT or
3.0.0-incubating-SNAPSHOPT (depending on semantic versioning - until there
are any new features only the patch level increase)

* Version of Taverna dependencies are declared in <properties> of the
top-level pom of each repository (NOT in Taverna Maven Parent) -- these
will gradually become non-SNAPSHOT as upstream modules have been released.

* To distinguish ourselves from the many 3.0.0-SNAPSHOT etc pre-Apache, we
bump one minor up from the highest version of the submodule. E.g. the new
command line is 3.1.0-SNAPSHOT

* The new version number should correspond with the highest non-Apache
submodule version, e.g. if a repository contains 10 modules that were
2.3.0-SNAPSHOT non-Apache, and 1 that was 3.0.0-SNAPSHOT, the new version
for all modules is 3.1.0-SNAPSHOT



On 5 February 2015 at 10:44, Alan R Williams <no...@github.com>
wrote:

> On 05/02/2015 10:21, Stian Soiland-Reyes wrote:
> > Less crazy is good. But this is security..
> >
> > I won't merge it in before the taverna-engine builds as-is (see
> > [Travis
> > failure](
> https://travis-ci.org/taverna-incubator/incubator-taverna-engine/builds/49472228
> ))
> > - probably it some pom.xml things or the recent scufl2 package
> > rename.
>
> The failure is almost certainly caused by me trying to rationalize the
> version numbers. I am tempted to revert the pom and take a slowly-slowly
> approach.
>
> Alan
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/taverna-incubator/incubator-taverna-engine/pull/1#issuecomment-73027014>
> .
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718

Re: [incubator-taverna-engine] Generally tidy up the code. (#1)

[alaninmcr <al...@googlemail.com>]

On 06/02/2015 14:40, Stian Soiland-Reyes wrote:
> Hm.. should we not switch back to the Apache Taverna parent?? :)

The Apache T3 is using the Apache Taverna parent. The sooner we close 
the master branches on github.com/taverna the better. It is very confusing.

Alan

Re: [incubator-taverna-engine] Generally tidy up the code. (#1)

[Stian Soiland-Reyes <st...@apache.org>]

Hm.. should we not switch back to the Apache Taverna parent?? :)

On 6 February 2015 at 13:59, alaninmcr <al...@googlemail.com> wrote:
> I've just looked at the travis errors and it appears to be because the poms
> do not specify Java 1.7 so it is defaulting to 1.4 and failing to compile
> lots of classes.
>
> It is the parent on the master branch of
> https://github.com/taverna/taverna-maven-parent/ that I broke :)
>
> Alan
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718

Re: [incubator-taverna-engine] Generally tidy up the code. (#1)

[alaninmcr <al...@googlemail.com>]

I've just looked at the travis errors and it appears to be because the 
poms do not specify Java 1.7 so it is defaulting to 1.4 and failing to 
compile lots of classes.

It is the parent on the master branch of 
https://github.com/taverna/taverna-maven-parent/ that I broke :)

Alan

Re: [incubator-taverna-engine] Generally tidy up the code. (#1)

[alaninmcr <al...@googlemail.com>]

Stian, apologies for the confusion.

I had been trying to "fix" the referenced bundles as specified in 
taverna-parent. Quite a lot of the ones where we used springsource 
bundles now have bundles created by the code originators. Also, because 
of confusion in mvnrepository, some supposed "jars" were actually 
bundles all along and need not have ever used springsource bundles.

I think it is safest to revert the parent pom to one that T3 CLT can 
build against and then slowly slowly update the bundle versions.

Alan