I think Gilles' reasoning is sound for semantic versioning and releases, in line with OSGi principles. However I think that would be better suited in a large or enterprise project with mainly internal usersnpf the libraries that can play along, not in Apache Commons which are making general availability libraries for the whole Java community.
So I'm afraid I agree with the quorum here, let's keep it simple with a single version across modules - it is so much easier for downstream users if we make the version in the distribution match the tag, which should match every module (and also the OSGi package version) Users with Maven can then just have a single $commons.foo.versiom property to update and it all plays along, as tested in our release candidate. Having to figure out the internal release policies and selecting across many different source releases is not just a barrier to use, but also for inviting new collaborators, they may struggle to know what to rebuild when fixing a bug. Another convenience argument for co-releasing is that the <dependencies> section will pull the latest friends, users won't have to manage each version to update, unless they want to deliberately stay behind "at own risk" (Commons won't have tested that combination) It does mean we sometimes get "pointless" upgrades on some modules where nothing has changed. As long as we are not claiming major/breaking changes, and don't use restricting (version,ranges] I don't think there is a big problem with that. The cases Gilles mention that is very much a potential scenario is where a -utils module does breaking changes, but the -api module has not broken anything. I think here we can be more lax about our package/artifact name change rule, so you *could* release foo-api 2.0.0 and foo-utils2 2.0.0. If foo-api later breaks, that would be foo-api3 3.0.0 (there was never a foo-api2) and foo-utils3 3.0.0 (not the very confusing double versioned foo3-utils2! ) On 26 Nov 2016 10:49 pm, "Jörg Schaible" <joerg.schai...@gmx.de> wrote: > Gary Gregory wrote: > > > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <joerg.schai...@gmx.de> > > wrote: > > > >> Sorry, for me this is going down the wrong road. For me different > >> versions mean different components. Allowing multiple versions for > >> modules in one component will exactly open the can of worms Gilles > >> described below. We had that already with Jakarta. > >> > > > > +1 and we do not need a Commons within Commons. > > > > For the case: > > > > commons-modproj-foo-1.0 > > commons-modproj-bar-1.1 > > > > You'd just release > > > > commons-modproj-foo-1.0 > > commons-modproj-bar-1.0 > > > > and then > > > > commons-modproj-foo-1.1 > > commons-modproj-bar-1.1 > > > > If nothing has changed in commons-modproj-foo between 1.0 and 1.1, then > > that's fine. You just get all your matching modules and you are done. > > > > > >> I still propose commons-rng-tools as separate component. Because of this > >> mail. KISS. > >> > > > > I'm not even in favor of that. Commons is already loose ecosystem of > > components, having sibling components will fog things up IMO. It's not > > just what's compatible with what according to some guidelines, it's more > > what has been tested with what so I can know for sure what will work. > When > > I get Commons Foo 1.3 and it has 10 modules, I know it's all MEANT to > work > > together, I KNOW it was all BUILT and TESTED together. > > > > Just keep it all in one component and make user's life easy. > > We already have dbcp depending heavily on pool. > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
