On Fri, 25 Nov 2016 11:55:57 -0800, Gary Gregory wrote:
On Fri, Nov 25, 2016 at 7:14 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Hello.
Thanks for all the replies.
However, it seems that when a project could make use of the
flexibility provided by modularization, there are objections
to really embrace it:
* Some don't like a partial release
* Some don't like different version numbers
* Some don't like releasing codes at different levels of
"achievement"
Clearly there is no consensus.
IMHO, a particular useful feature of modularization is to
allow the respective versions to reflect the actual state of
the code contained in the corresponding module.
Otherwise the (single) version is misleading for some of
modules and meaningless for others.
I can understand that version varying across modules requires
careful attention; but is there a problem in principle?
Won't tools such as Clirr readily spot failures to comply with
compatibility requirements?
Using again the practical example, and trying to mix and match
opposite POVs, here is a suggestion.
Release all "productive" functionality:
commons-rng-client-api -> 1.0
commons-rng-core -> 1.0
commons-rng-simple -> 1.0
commons-rng-sampling -> 0.8
Question for the latter (from the other thread):
When "sampling v1.0" is released, can it break compatibility
with "sampling v0.8" ?
I guess not.
I understand thus that version numbers below 1 are utterly useless.
In effect, if there is a release of package
org.apache.commons.rng.sampling
with version, say, 0.8.
Then when version 1.0 is released, the package must change to
org.apache.commons.rng1.sampling
unless ...
You could also remove any jar hell risk by packaging 0.8 in an
.alpha. package.
... everything released with version < 1 must be in an "alpha"
package
org.apache.commons.rng.alpha.sampling
Is that a rule? [Anyways, I find it prone to confusion.]
All in all, you confirm that having modules is not giving
any flexibility in release management: codes that would not
strictly require being released together, are forced to
share the same version number.
[The unavoidable consequence is that another component (a.k.a.
"RNG Utils") was the simple and flexible approach.]
On a slightly different note, by assuming that 0.8 would fit
as a version, I might have made it look like the sampling
package is not ready, and you implied that it should not be
released.
Quite the contrary, it is certainly not worse that code
released many times over in Commons Math.
And, with the new 64-bits generators, the continuous
distribution samplers should even be faster.
I can only repeat a statement of fact: I worked on the
design much less than I did for the other modules (a
couple of weeks vs almost a year).
But the functionality is quite usable (as it was deemed
usable in Commons Math).
I'd say that we have to choose between
(a) allowing different versions in modules (and IIRC Stian
said that no Apache rule does forbids it), or
(b) assuming that version numbers are meaningless (in cases
like "Commons RNG") beyond being a counter, or
(c) when (b) happens requires the creation of a new
component.
I've no blocking problem with option (b); just let me know.
Gilles
Gary
Release code only useful for internal development (e.g.
checking that a contribution does degrade performance),
with a suffix that indicates so
commons-rng-jmh -> 1.0-dev
There is no obligation to provide benchmarking code, is there?
Publishing results on the web site is already much more than
other components do.
Release usage examples with a version number and suffix
indicating that no comptatiblity is to be expected:
commons-rng-examples -> 0.0.1-beta
[Is there a better "suffix"?]
WDYT?
Regards,
Gilles
On Fri, 25 Nov 2016 13:34:04 +0100, Jörg Schaible wrote:
Hi,
Stian Soiland-Reyes wrote:
I think I'll tend towards agreeing with Jochen here, rather get
half the
modules out early than fight ourselves with versioning workarounds
if the
rest of the modules are not ready for prime time.
However I see concerns of selective "part releases" and
reproducible
builds, so I would do this using Maven profiles - the release
profile can
have a smaller <modules> set.
I then think all the modules that appear in the src release should
also
go
to Nexus as binaries, even if they are more exotic "internal"
modules. I
would not mess around with selective deployment as it is a recipe
for
maintenance nightmare and manual mistakes.
It only gets tricky if the leftover modules get a release cycle of
their
own.
It is OK if the -bin release don't have all modules, that is more
of a
convenience of jars that are useful out of the box.
The -src artifact is a different case. It should contain anything
independent of the published modules' artifacts (and it can,
because it
depends on the file patterns in the assembly). It is always a
hassle if
you
have no direct possibility to fetch the matching source of the
examples
(and
even the JMH stuff) for an individual release. Directing users to
GIT is
not
very convenient.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
