Regards,
Gilles
>
> 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
>> >>>
