I personally think that semantic versioning for packages is the main thing. We should keep that and I think there is no disagreement about that. Personally I don't care what the versions of the bundles are. People should not be doing Require-Bundle anyway.
The one thing that I think would be good to keep is the option to release individual bundles if there is a desire to do so. Let's say there is a small bug in a certain bundle, then I think it should be possible to just release that individual bundle, as we have been doing in the past. I.e. I think we should not be *forced* to do the big bang release. Just my 2c, David On 22 May 2015 at 17:25, Jeremy Hughes <[email protected]> wrote: > On 22 May 2015 at 16:15, Daniel Kulp <[email protected]> wrote: >> >>> On May 21, 2015, at 11:44 AM, Jeremy Hughes <[email protected]> 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 >>> www.apache.org/dist/aries. >> >> 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 dist.apache.org, 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 > versions. > > 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 :-) > > Jeremy > >> >> Dan >> >> >> >> >>> >>> 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 >>>> >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >>
