I think everything would be much easier to just maintain one version per repository. Besides, it would get confusing having multiple git tags or svn tags for different component versions, especially if a repository uses short tag names that only include the version number and not the component name.
On 27 November 2016 at 07:36, Rob Tompkins <chtom...@gmail.com> wrote: > I forgot to mention that it seems to me that this (a singly versions block > of code) is the fundamental "meaning" of what a repository is. I mean that > in the sense that if you want separate separately versioned components, > that is a direct argument for separate repositories. > > With that said, I'm not opposed to the conversation of enabling separately > versioned portions of rng by pulling them out into other repos, but that > bumps into the definition of a "commons" component. > > Either way these are just thoughts and not hard and fast rules. I don't > feel overly tied to any position here. > > Cheers, > -Rob > > > On Nov 27, 2016, at 8:12 AM, Benedikt Ritter <brit...@apache.org> wrote: > > > > 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 > >>> > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
