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


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

JUnit in Action, Second Edition

Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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