Preface: This thread, the questions it contains, as well as other recent emails in general feels like the result of the normal learning curve one must go through when dealing with a Maven multi-module project. This is time well-spent IMO as most non-trivial (>1 jar) projects are multi-module projects.
Now for the meat: Strictly speaking, Apache Commons (and all Apache projects) release sources as the official release artifacts on Apache "dist" servers. Any binary files we provide are a convenience whether on Apache servers or Maven Central. That means that ALL sources for a component (Apache Commons RNG in this case) must be released in the -src ZIPs and GZs. I'd like to hear a good reason not to do that. If a module is not ready for prime time, then I suppose it could either be excluded or packaged in an module and package with an appropriate artifact ID and name (like .ea/-early-access or .experimental/-experimental). It makes the most sense if the -bin version of a component contains the result of building what is in all of the -src ZIP/GZ. So that would be a "no" to (a). "[Rationale is that it would allow to make changes without bothering about compatibility with _unintended_ uses.]" You should make it clear which module you guaranteed binary compatibility. For example, in Log4j 2 we do our utmost to keep the API module 100% BC. For all other modules (there are a few), we make no such guarantee but also try not to make our user's life difficult. I cannot imagine that you'd want to provide 100% BC for a performance measurement or examples module. It seems obvious to me, but you might as well state it front if you think there could be room for confusion. For (b), that's a recipe for confusion and guaranteed questions on the ML or bug reports in JIRA. Especially when it is easier to release to Nexus than it is manually copying files around SVN (or writing a script to do so). For (c), that's another recipe for confusion. Apache Commons is special in the sense that it is ONE Apache project that releases COMPONENTS like Apache Commons IO, Apache Commons Lang and so on. When a component is released, all modules it contains come along for the ride. Anything else is going to be a mess IMO. A 1.0 release is not only the first release but it is also a MAJOR release, setting the public APIs in stone for 1.x. Breaking BC in a public API means a major version change, a package change, and matching artifact ID change. That's how we avoid jar hell. Noe that you get to define what public means BTW, this and that module but not this other one. Even within a module you can make it clear what APIs are public by "hidding" private APIs in specially named packages (IIRC, Eclipse uses ".internal." for example). If you really want to push to a 1.0 and some of the code is not ready, you can do that but you really should move that code to "I'm an experiment" package. Then when that code is ready, you can release a 2.0 version with the new shiny code in a public package. Or you could COPY it to to the public package in a 1.x release, YMMV. It may seem like I am contradicting myself but there are many ways to do this and play nice by BC rules. I hope this helps! Gary On Thu, Nov 24, 2016 at 6:05 AM, Gilles <gil...@harfang.homelinux.org> wrote: > Hi. > > The "Commons RNG" component (in the "Apache Commons" sense), > consists of the following modules (in the "maven" sense) that > provide Java code: > (1) commons-rng-client-api > (2) commons-rng-core > (3) commons-rng-simple > (4) commons-rng-sampling > (5) commons-rng-jmh > (6) commons-rng-examples > > One could see the RNG low-level "library" as composed of (1), > (2) and (3). > (4) is higher-level; it depends solely on the "UniformRandomProvider" > interface defined in (1). > (5) does not provide any functionality to application developers. > (6) contains working code that is either of interest to "Commons > RNG" contributors (for running the "stress" tests) or currently, > fairly trivial (and not recommended) examples of use of the > "library". > > Questions: > > a. Is it OK if the official release does not contain (5) and (6)? > [Rationale is that it would allow to make changes without > bothering about compatibility with _unintended_ uses.] > b. If so, is it still OK to provide JARs for them via the web site > (but not upload them to Nexus)? > c. Is it OK that the modules have different versions (reflecting > the perceived status of development)? > [This is related to the "commons-rng-sampling" issue of the > post with subject "Ralease policy for version < 1".] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
