On Fri, Nov 25, 2016 at 3:45 AM, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote:
> Hi, Gary, > > > I humbly disagree on your response to Gilles questions. In more detail: > Humility not required, let me have it! ;-) [or let the technical points have it] > > > 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.) > Are you suggesting that an uber jar be available? That's always a good thing IMO. I find the two list items above in contradiction with each other. > > 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". > We've recently seen some multi-module releases: Commons JCS and Commons Weaver. It's harder, sure but there is experience around here to help. > > 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. > I agree. Gary > > > 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 > > -- 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
