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 situation. rng-core and rng-utils are developed by the same team and target the same field (random number
generation and its direct applications). The JDK and "some-lib" are
completely unrelated.

"some-lib" uses the JDK

just as

"rng-utils" uses "rng-core"

The comparison is adequate, if you consider the examples I've given
(avoiding upgrades when no code change happened).

I agree that the mixing of versions, even if allowed,
is not the best choice; that's why I've argued from the
outset that such loosely coupled modules must in fact
be different components!

The result will be that, indeed, users must choose from
compatible versions.  Anything new under the Sun?

As mentioned by Stian this is how work httpcore and httpclient, and this can be confusing and error prone. If the modules are all aligned on the same version the users have only one version to update (typically with a
Maven/Gradle property) and there is no risk of version mismatch.

I don't deny that tools such as maven or ivy can download a new
version automatically.
Nevertheless, I envision that "rng-core" will change at much slower
pace that "rng-utils", many such upgrades will download the exact
same code.

Also, contrarily to what Artem suggested, I also envision that
most of "rng-core" will change in a compatible way (e.g. add
new RNG implementations), so that "rng-utils" does not need to
be released in sync.

Yes, for some time, users of the syntactic sugar factory won't
be able to use it in order to instantiate the new RNG. So what?
[How is that different from a library sticking to Java 6, and
thus cannot use the features of Java 8?]

Can we please go away from the monolithic culture (and
look at what other libraries do, and at what IIUC the
JDK is going to do in the next major release)?

By definition a modular structure isn't monolithic, that's exactly what other libraries do. And it isn't incompatible with the Java 9 modules.

I'm all for modular structure, but against unnecessary dependence
of release cycles.
They are two different things.

In the examples you gave, I could certainly trust you that a
release cycle dependency exist.
I don't see that in my vision of "rng-core" and "rng-utils".

It seems like the number of components were a limited
resource.  This kind of conversation is truly wasting
valuable time that could have been better spent in setting
up "rng-utils".

It seems like folks here are happy to make things more
complex than they intrinsically are.

Let's talk about complexity. Separate projects mean:
- Extra work for the infra team to setup the project

Thanks to all people giving time!

INFRA people will create this repository when it suits them.

Then I (and you) will save huge amounts of time because we
won't have to fight over what goes where, thanks to well-scoped
components and separation of concern.

- Users must carefully pick the compatible versions for the projects

Same as any application does already.

- JIRA reports are likely to be mixed (RNG issues reported in RNGUTILS
and vice versa)

Perhaps.
I'll move them. OK? ;-)

- Extra release management work

I'll do it. OK?

- Extra project maintenance (parent and dependencies updates, etc)

I'll do it. OK?

- Extra filter rules to setup for the people subscribed to the ML

Go complain to the PMC.
[I'm all for separate MLs, as people have been recurrently
proposing.]

- 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 build of "rng-utils", can't this be done by a "post-build"
script?

That doesn't look easier than one multi-module project to me.

You are mixing tools issues (which we can address as I just did
above) with principle: Whether "rng-core" and "rng-utils" are
sufficiently interdependent to make them part of a single
codebase.  If not (my POV), then managing them together is
more complex (because there is factually more ways to break
something).

If that is not obvious to you, but are willing to trust other
members here (me in this case), you could agree to make the
experiment! :-)
Then when we see more code, more users, more contributors,
more opinions, and we see that there is merit in merging the
two components, we'll just do it.
[And I'll apologize to the INFRA people for the time they wasted
in setting up the project.]

Deal?


Gilles

Emmanuel Bourg




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to