Hi, Gary,
I humbly disagree on your response to Gilles questions. In more detail: 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.] A release is a release, because it fulfills the typical requirements (ASL licensed, source first, binary is for convenience only, LICENSE.txt, and NOTICE.txt, etc.) and, most importantly, because the PMC endorses it as such. I can't think of any reason, why the PMC should refuse a release, if it fulfills the requirement, just because the source release can be used to build four jars only, and not six. At least, I'd be glad to vote +1 in such a case. That being said, and having had the experience of a multi-module project (Apache RAT) in the past, I strongly recommend that RNG - abstains from full releases (all six jar files) and - starts by pushing out single jar files by default (in whatever order seems to make sense). (Possibly more than one at once, okay.) Otherwise, I have learned that the hurdle to push out a release can become overwhelming, and leads to deferring releases endlessly. Forget "release early, release often". Besides, you'd have to maintain varying build scripts, or even worse: Create individual build scripts, depending on what is being released. Not, what I would like to see in a project of mine. b. If so, is it still OK to provide JARs for them via the web site (but not upload them to Nexus)? For all practical purposes, Nexus is more important nowadays for distributing binary jars, than the ASF web site. The source archives are another story, of course, as they constitute the actual release. Those *must* be available from the web site. 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".] If they are successfully voted upon: Why not? Jochen On Thu, Nov 24, 2016 at 7:01 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
