Hi.
On Thu, 29 Sep 2016 11:48:29 +0100, Stian Soiland-Reyes wrote:
Having all modules in the project have the same is just a
convention.
That's not what I've been told.
Anyways, I agree that interdependent modules _of the same project_
should preferably share the same version number.
It cou
On Fri, 30 Sep 2016 10:45:47 -0500, Brent Worden wrote:
On Fri, Sep 30, 2016 at 10:02 AM, Gilles
wrote:
On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
- No immediate Jenkins feedback if a rng-core change breaks
rng-utils
I'm not sure I got that one.
If it means to copy the
Hi All,
[Note my careful use of the terms "project", "component", and "module"]
Pardon my jumping in late... If some of this is leading to more than one
commons-rng component within Apache Commons, I would be against that; Maven
modules are a perfect match for this concept.
Please allow me to re
On Fri, Sep 30, 2016 at 10:02 AM, Gilles
wrote:
> On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
>
>>
>> - No immediate Jenkins feedback if a rng-core change breaks rng-utils
>
> I'm not sure I got that one.
> If it means to copy the new "rng-core" over to some place for use
> by the
On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
Le 29/09/2016 à 13:59, Gilles a écrit :
What you are arguing here is that if "some-lib" is
upgraded, then the JDK must change version too!
Does that (extreme) comparison make the issue clearer?
No, because it isn't comparable to our s
On Fri, 30 Sep 2016 09:49:52 +0200, Emmanuel Bourg wrote:
Le 29/09/2016 à 14:01, Gilles a écrit :
I think other modules will be somehow dependent on rng-core, so
change
in core will require additional release of the module.
Wrong!
See previous post(s).
Actually Artem is right. Changes i
Le 29/09/2016 à 14:01, Gilles a écrit :
>> I think other modules will be somehow dependent on rng-core, so change
>> in core will require additional release of the module.
>
> Wrong!
>
> See previous post(s).
Actually Artem is right. Changes in rng-core are likely to be used in
rng-utils. For
Le 29/09/2016 à 13:59, Gilles a écrit :
> What you are arguing here is that if "some-lib" is
> upgraded, then the JDK must change version too!
>
> Does that (extreme) comparison make the issue clearer?
No, because it isn't comparable to our situation. rng-core and rng-utils
are developed by the
Le 29/09/2016 à 12:23, Gilles a écrit :
>> And multiple projects would hypothetically ease one migration every five
>> years?
>
> This would happen for _every_ release.
How do you come to this conclusion? We are talking about an incompatible
update, the kind of update that forces to change the n
On Thu, 29 Sep 2016 14:41:11 +0300, Artem Barger wrote:
On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes
wrote:
A good question is - if rng-core changes - would the other modules
need to change as well? If not, then there's not a big reason why
they
need to be together in the same proje
On Thu, 29 Sep 2016 13:40:08 +0300, Artem Barger wrote:
Hi,
What you are arguing here is that if "some-lib" is
upgraded, then the JDK must change version too!
Does that (extreme) comparison make the issue clearer?
I agree that the mixing of versions, even if allowed,
is not the best choice;
On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes
wrote:
> A good question is - if rng-core changes - would the other modules
> need to change as well? If not, then there's not a big reason why they
> need to be together in the same project (but we would end up with
> Commons Commons Component
Having all modules in the project have the same is just a convention.
It could make sense to increment the rng-core module more slowly,
while still allowing it in the build.
For instance:
commons-rng 1.2.0 could include:
rng-core 1.1.2 (nothing actually changed, but we can't re-deploy 1.1.1)
Hi,
On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg wrote:
>
> >> Multi-module projects are quite common and the case you mention isn't
> >> unusual.
> >
> > Please show an example.
>
> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
> There is no lack of examples. Multi-
On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
Le 28/09/2016 à 15:58, Gilles a écrit :
Multi-module projects are quite common and the case you mention
isn't
unusual.
Please show an example.
Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
There is no lack of e
Le 28/09/2016 à 15:58, Gilles a écrit :
>> Multi-module projects are quite common and the case you mention isn't
>> unusual.
>
> Please show an example.
Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
There is no lack of examples. Multi-module projects routinely publish
new r
On Wed, 28 Sep 2016 14:17:19 +0200, Emmanuel Bourg wrote:
Le 27/09/2016 à 01:14, Gilles a écrit :
An additional module in Commons RNG will not help, as was noticed
some time ago: it won't be possible/allowed to release the modules
separately.
I don't want to have to release a major version of
Le 27/09/2016 à 01:14, Gilles a écrit :
> An additional module in Commons RNG will not help, as was noticed
> some time ago: it won't be possible/allowed to release the modules
> separately.
>
> I don't want to have to release a major version of Commons RNG
> just because accessory tools requires
18 matches
Mail list logo
