commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [ALL] Version number(s) for modular components
Date Sat, 26 Nov 2016 22:49:36 GMT
Gary Gregory wrote:

> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <joerg.schaible@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message