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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] 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
