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 www.apache.org/dist/aries.
What would be published to maven central? I think we would need the top-level-module zip release as well as the individual bundles e.g. for http://jpm4j.org/ (which queries maven central and figures out what packages are in what bundles) and for Bndtools integration (which uses jpm4j for that purpose). I think we need to keep the semantic versioning of our packages consistent going forward - for people doing import-package imports (hopefully most users). Ideally we would keep semantic versioning of the bundles consistent going forward too - for people doing require-bundle. 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. Thanks, Jeremy On 20 May 2015 at 16:12, 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 >
