aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [Discuss] Release whole sub projects instead of individual bundles
Date Thu, 21 May 2015 13:46:21 GMT

I have to agree with this.  One of our goals really needs to be to “release” software
that we’re working on.   The current setup really makes things much much harder than it
needs to be to do the releases.   I’ve done several blueprint releases and collecting the
various things that “need” releasing is a pain.

In addition, it makes it much harder for users to consume the releases. Knowing which bundles
were built and tested together is nearly impossible.   Upgrading to the latest releases is
a pain as you have to check versions for all kinds of things.   

The migration to git is another good reason. :-)  

The only thing to be aware of is to avoid the use of “sub project”.   That tends to raise
flags.   “Per technology module” release or something.    


> On May 20, 2015, at 11:12 AM, 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