hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: New features / new APIs in patch releases (x.y.Z)
Date Sun, 19 Mar 2017 07:55:37 GMT
Hi All,

- Do we have any idea of our user's expectations? Is HC knows for adhering
to Semantic Versioning? Have we done so in the past?

- Why not just make the version numbers evolve following what the code
does? If we add new APIs and we are backward compatible, then that can be a
minor release 4.5.x -> 4.6.0 for example. If we do that very often, then we
can end up with versions like 4.15.0 and that's fine. We can avoid wringing
our hands when we want a maintenance version like a 4.5.3 -> 4.5.4 to
contain new APIs.

- Are there hidden costs to releasing minor releases as opposed to
maintenance releases? Right now, we use branches it seems. We can keep
doing that or just have a 4.x branch until we need another specific 4.x.y
branch.

Gary

On Sat, Mar 18, 2017 at 7: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
>
>


-- 
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