On Wed, 17 Aug 2016 00:42:47 +0200, Jörg Schaible wrote:
Gilles wrote:
On Tue, 16 Aug 2016 15:53:44 +0300, Artem Barger wrote:
On Tue, Aug 16, 2016 at 3:00 PM, Gilles
<[email protected]>
wrote:
That's what I was afraid of; in this case, it would defeat the
purpose:
We shouldn't have to release "core-2.0" (thus a with change of the
top-level package name), just because we want to fix something in
the
"utils" code.
Given this situation, would it be possible to consider a separate
component: "commons-rng-utils"?
I think following layout should actually work:
commons-rng-parent (pom) v1.0
|____commons-rng-core (jar) v1.0
|____commons-rng-tools (jar) v1.0
And suppose you want to update commong-rng-tools from v1.0 to v2.0
it will
look like:
commons-rng-parent (pom) v1.1
|____commons-rng-core (jar) v1.0
|____commons-rng-tools (jar) v2.0
where you do not really have to touch version of core component.
Unless
this is somehow
restricted by ASF commons coding standards or something.
The restriction, as Jörg wrote, is that a single component can only
release artifacts with the same version.
It's also the tooling. What should Maven tag for a release?
I just wanted to have 2 separate releases.
Do you mean that it would require "pom-core.xml" and "pom-utils.xml"?
And consequently, it would be functionally equivalent to 2 separate
components?
I'm fine with that (hence my post for considering it).
If we have to put the tools in a separate component, it will already
inherit from "commons-parent". Then, is there an interest to define
an additional "commons-rng-parent" level.
I don't think you'd gain something for an additional parent.
I agree (I forgot the question mark in the previous sentence).
Gilles
What would it
contain?
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
