On 2017-06-07, Bertrand Delacretaz wrote: > On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg <ebo...@apache.org> wrote: >> ...Do I understand well that we would have to micro manage versions at the >> package level different from the version at the component level, and >> sometimes significantly different versions (like foo 1.2.3 and >> org.apache.commons.foo.bar 2.3.4)?...
> That's how it's done in OSGi-based systems. >> ... That sounds like a nightmare... > With the right tools as mentioned in my previous message it's quite easy. >> ...What existing problem would that solve exactly?... > Implementing semantic versioning at the java package level as opposed > to bundle level. > In heavily componentized systems that's a big help, assuming the Java > packages make sense - to paraphrase Grady Booch, one package should do > one thing and one thing well. > On the other hand, if you don't care about package-level versioning > and consider your bundle as one big thing on which other things > depend, that doesn't help much. Compress, which is targeted by Simon's pull request, is probably one of the few components where package level versioning might make sense. For most of our releases the packages are independent of each other and many of our implementation packages don't change at all with new releases. I'm not a citizen of OSGi land and find it hard to fully understand whether the suggested changes make things better in any way. Right now we bump all package level versions together with the artifact. We intend to use semantic versioning, if we've failed to do so in the past, then this is the problem more than whether the version applies to the package or the library as a whole. So I've got a bunch of practical questions: Say we started versioning packages with 1.15 and all untouched APIs stay at 1.14. We update package versions whenever there is an API change. We go ahead and fix a problem with an implementation detail in - say - "ar" in 1.19 but there is no API change. Would we modify the package version? What if we change the implementation in "util", not in "ar", what is going to happen to the version in "ar"? What will the bundle plugin tell us? Would this mean we'd need to start using bugfix version numbers for packages where the implementaion changes but the API doesn't? I.e. "ar" in Compress 1.19 would have version 1.14 (no API changes) or 1.14.5 (five implementation changes since 1.14)? How would we tell our users to upgrade to version 1.19 in order to use a bug fix that has been applied if this is the version of the library as a whole and not the version of a package? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
