n 23 May 2015 at 13:50, Christian Schneider <[email protected]> wrote: > I agree that the semantic versioning of the packages is the most important > thing. It will provide highest possible isolation from changes for user > bundles. > We are also quite accustomed to do so with the help of the version plugin. > > For the bundles I would propose the simple approach to keep all bundles of a > subproject at the same version. We should increase this version roughly
I agree. Can we define roughly though? I can't see any reason to bump any of the version numbers more than one of its constituent packages has been. i.e. a fix in an Aries JPA package bumps the micro of the package, all the Aries JPA bundles and the Aries JPA distro of all bundles. Likewise with API additions (minor version bumps) and API breaking changes (major version bumps). > according to semantic versioning. For example it should be rather easy to > make sure bugfix versions do not change APIs and do not add new > functionality. > One awkward change of course is if we do an API change in one package. We > will then probably have to increase the major version of the whole > subproject even if many packages stay exactly the same. As for example the > OSGi API jars have the same issue I would not regard this as a big problem. I agree, that's the trade off. > As long as we version the packages correctly, user code will still behave > well if they use import package. > > I also agree that people will still be able to put together their set of > individual bundles from maven central. The challenge for these people is knowing when to update. We'll be requiring ourselves to release unchanged bundles with a micro/minor or major version bump. When someone sees a newer version, it's very tempting to update even if there are no changes. Which would you rather use bundle v1.1 or v1.2 even if it is stated they are identical? > Though most people probably will just > use the set of bundles we provide together anyway as you need quite deep > knowledge to pick individual bundles and still make the system work. I could argue this both ways - deploying a set of bundles that have all moved up a version, but only one of which has inherent changes - is a risk. Equally, deploying only the single that did change means combining it with bundles it may not have been tested with (although if the others haven't changed the risk should be minimal). > > Christian > > On 22.05.2015 18:25, Jeremy Hughes wrote: >> >> 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 > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
