commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [RNG][ALL] Official vs "courtesy" code ?
Date Fri, 25 Nov 2016 19:49:19 GMT
On Fri, Nov 25, 2016 at 3:45 AM, Jochen Wiedmann <jochen.wiedmann@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 <garydgregory@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 <gilles@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message