I'm also in the "one-version per repository"-camp. Benedikt
Stian Soiland-Reyes <st...@apache.org> schrieb am So., 27. Nov. 2016 um 11:48 Uhr: > 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 > > > > >
