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. > 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. > 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. > 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 - Users must carefully pick the compatible versions for the projects - JIRA reports are likely to be mixed (RNG issues reported in RNGUTILS and vice versa) - Extra release management work - Extra project maintenance (parent and dependencies updates, etc) - Extra filter rules to setup for the people subscribed to the ML - No immediate Jenkins feedback if a rng-core change breaks rng-utils That doesn't look easier than one multi-module project to me. Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
