On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
On Sat, Sep 2, 2017 at 12:50 AM, Gilles
<gil...@harfang.homelinux.org> wrote:
Because of "Commons" rules, it is not "equivalent": There was
a long thread concluding that all modules must be released
_together_, and with the same top-level package name and version
number.
It is very "maintainer(s)-unfriendly" because of the quite
different subject matters that coexist in CM.
I wouldn't count that rule "*all* modules must be released" as a
mantra:
I found the idea attractive, but Stian (link to older discussion
in a previous post) advised that maven would not easily "support"
it.
Has that changed since the discussion took place (10 months ago)?
a) In case of an emergency release (fixing a CVE, for example), I'd
clearly consider pushing out the module as more important than
waiting
for a full release. (Of course, one must be careful to maintain
compatibility when pushing out just a module, but that goes without
saying.)
b) I'd like to hear others experiences on that topic (maybe VFS).
Anyways, my personal experiences with Rat are clear: Releasing *all*
together is causing nothing but pain, and tends to defer releases
indefinitely. OTOH, releasing a submodule can be done at all times,
and without overly much preparation.
In conclusion, I'd definitely support the release of a single
submodule, if the need would arise.
How can one reconcile what you say here with what was said in
that old thread?
Would the PMC accept that a component contains independent modules
(where "independent" means that each module can have its own version
number, irrespective of the component's version)?
Arguably (cf. thread referred to above), a "Commons" component
should be simple enough that multiple versions are not necessary.
[Chorus:] This is not the case with "Commons Math", hence separate
components for independent contents (such as "Geometry", "RNG",
"Numbers" and "SigProc") is the simplest solution.
Gilles
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
