hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: New features / new APIs in patch releases (x.y.Z)
Date Sat, 18 Mar 2017 19:41:23 GMT
I have a sense as to what is driving this, of course, but here are some
principles that we use in ManifoldCF:

(1) It's always a tradeoff between the severity of the issue and the
frequency of releases; if the Next Minor Release is due in a month, then
there's a high bar for adding features or API changes to a point release.
(2) There's never a good time to release stuff that breaks backwards
compatibility; that's why there are major major releases like 5.x.x.
(3) General care needs to be taken not to inadvertantly make stuff part of
the API that shouldn't be, whenever it happens.
(4) We're not religious about taking stuff out of the class API that was
never intended to be public, even at a point release.  So far we've heard
of nobody being inconvenienced by this, but HttpComponents is more widely
used and thus greater care is appropriate.

Hope that helps...
Karl


On Sat, Mar 18, 2017 at 2:26 PM, Oleg Kalnichevski <olegk@apache.org> wrote:

> Folks
>
> I would like to have a rough consensus whether or not it is OK to put
> new features / new APIs in patch releases.
>
> There are several things about adding APIs in patch releases that can
> potentially cause issues
>
> * Those changes do not go through the standard alpha / beta / GA
> development cycle, which means less testing and almost no feedback
>
> * Once released those changes permanently become a part of public APIs
>
> * Incompatibility between patch releases can go undetected as Clirr
> maven plugin is usually configured to test against the feature release
> (for instance 4.5.x releases get checked against 4.5.0 and API
> incompatibility in classes and methods added after 4.5.0 will not be
> detected).
>
> Naturally having to drive every trivial API change through the standard
> alpha / beta / GA development cycle means more overhead, more work and
> more trouble (primarily for me, as for better or worse I act as a RM
> for most releases).
>
> I have no intention of trying to be more Catholic than the Pope of
> Rome. It will be perfectly fine for me if we all collectively decide it
> is not much of a problem, as long as we make this decision explicitly
> rather than implicitly.
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

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