aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: [Discuss] Release whole sub projects instead of individual bundles
Date Fri, 22 May 2015 16:25:14 GMT
On 22 May 2015 at 16:15, Daniel Kulp <> wrote:
>> On May 21, 2015, at 11:44 AM, Jeremy Hughes <> wrote:
>> Hi,
>> Simplifying the release process would definitely be good. I'd like to
>> know the detail of what you're suggesting. I think you're saying that
>> a release of (say) Aries JPA would contain all the artifacts the child
>> modules release today... plus tests plus samples. The release would be
>> a src and a bin tgz/zip file and would go up on
> Correct.
>> What would be published to maven central?
> Yes.   That wouldn’t change.   It would be easier as things would pretty much be in
a single staging area in Nexus.
>> I think we need to keep the semantic versioning of our packages
>> consistent going forward - for people doing import-package imports
>> (hopefully most users).
> Package level exports would remain as is and be completely semantic versioned.
>> Ideally we would keep semantic versioning of the bundles consistent
>> going forward too - for people doing require-bundle.
> This would change.  All the bundles for the release would have identical version numbers.
>> We could introduce a new 'top-level-module' version which wouldn't be
>> used at runtime, but would help in aggregating together a set of
>> bundles that are consistent with each other & well tested etc.
>> So, if we
>> * always release at the top-level-module level and
>> * keep the way we do package and bundle versioning going forward, and
>> * publish the individual bundles from the release into maven central
>> with their existing well known co-ordinates
>> would this work for you? I'm slightly concerned in writing this, that
>> this might not provide enough simplification in the build process,
>> although it would mean a single artifact (well src and bin) to vote on
>> even though that results in multiple artifacts being published to
>> maven central.
> All the jars/bundles in the “module” would have identical version number.  The exports
in the bundles would be semantically versioned correctly.  There would be a single “src.tar.gz”
and “bin.tar.gz” for, but each bundle would also be put in central individually
with their “sources.jar” and javadoc jars (for IDE integration).   A release of all of
a “module” can be done with a single “mvn release:prepare; mvn release:perform” which
would pretty much handle everything.

Some consequences: every release we do we'll bump the bundle version
numbers so they're all the same. The bundles will individually be
uploaded to maven central so a minor version change caused by a single
bundle will cause other, unchanged bundles to also get a bump.
Consumers of an unchanged bundle in the changed module could be fooled
into thinking there is something new for them. We should do some
education saying: forget the bundle versions when you want to update
because you may not be getting an update - just look at the package

So, I'm wondering whether we should semantically version the "module".
While there is less reason to, I think it makes sense - to give users
an idea of the significance of the changes inside. That leaves us in
the position where "modules" are semantically versioned, but nothing
consumes them in that way (other than users), bundles are not
semantically versioned, although some code does consume them in that
way (Require-Bundle for example), and packages remained semantically
versioned. I feel the last point is the most valuable. I think the
ease of releasing code outweighs the loss of semantic versions on
bundles despite the future of many differently versioned identical
bundles proliferating on maven central. At least users can see what
the consistent set is - what we've tested together, AND they can
consume individual bundles from maven central - which is really
important for me.

As you can see I'm just about coming down from the fence in favour :-)


> Dan
>> Thanks,
>> Jeremy
>> On 20 May 2015 at 16:12, Christian Schneider <> wrote:
>>> Currently we release each bundle separately and we do not release tests and
>>> examples at all.
>>> This approach is very fine grained and tedious if several bundles need to be
>>> released. Probably Holly can tell some stories about the fun of releasing
>>> aries 1.0.0.
>>> So I would like to discuss changing to a more coarse grained model.
>>> The idea is to release per "sub project" like e.g. Aries JPA. This would
>>> mean that we always release all bundles of a sub project even if nothing has
>>> changed.
>>> Of course we would still version exported packages according to semantic
>>> versioning rules. So apart from having some additional bundle I do not see a
>>> big disadvantage in the coarse grained model. Users could still depend on
>>> the old api and still work with newer releases if the API did not change.
>>> On the other side there are a lot of advantages for releasing per sub
>>> project:
>>> - Easier to understand for users.
>>>    They could say I am using Aries JPA 2.0.0 instead of saying I use
>>>    org.apache.aries.jpa.api 1.0.2, org.apache.aries.jpa.blueprint.aries
>>> 1.0.4, org.apache.aries.jpa.container 1.0.2,
>>> org.apache.aries.jpa.container.context 1.0.4
>>> - The jira structure would be simpler as we would only need one version per
>>> sub project
>>> - We could migrate to git at last as we could then have one git repo per
>>> subproject that could be nicely branched and tagged on the repo / sub
>>> project level.
>>>  One other nice thing would be that we could move to git gradually one sub
>>> project at a time without disturbing the others.
>>> - We would tag the tests and examples together with the production bundles.
>>> This makes it much easier to run tests against a specific release version.
>>>    This should also make it much easier to maintain bugfix branches and
>>> make sure they are properly tested.
>>> - Per apache policy we have to store all releases at
>>> With the current fine grained model almost no one
>>> seems to do this. This should also be easier with more coarse grained
>>> releases.
>>> What do you think?
>>> Christian
>>> --
>>> Christian Schneider
>>> Open Source Architect
> --
> Daniel Kulp
> -
> Talend Community Coder -

View raw message