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. Dan > On May 20, 2015, at 11:12 AM, Christian Schneider <[email protected]> > 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 > www.apache.org/dist/aries. 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 > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
