On Thu, 2022-06-02 at 07:37 -0500, Steve Ebersole wrote: > > But in the end, given a large enough userbase, every > > (documented or undocumented) behavior of an API is being relied > > upon by someone, meaning that every change will break someone's > > workflow: https://xkcd.com/1172/ > > Extrapolating what you say, we could never fix bugs because that > buggy behavior is "being relied upon by someone". I simply reject > that. Fairly sure that is not what you are saying, but this has been > my point throughout this conversation - words are important. > Especially when you start talking about expectations across a large > number of people.
Well I did not say that you "could never fix bugs", just that a bugfix has a certain probability of being a breaking change for some user out there. As your userbase grows, that probability approaches 1. Semantic Versioning actually recognizes this issue: in the introduction, the authors state that for SemVer to work, you must first declare a public API, then communicate changes to it using the version number. That way, a "backwards-compatible bugfix" is truly backwards compatible for users that strictly implement your public API. From what I've seen in the documentation, it looks like Hibernate now has a clear distinction between the public and private API (you describe this in "Huge Project, Small Team" [1]). So, kudos :) [1] https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team#internal > > I meant that the Hibernate developers once in a while have to > > say to each other "Let's stop backporting fixes for release series > > x.y. People have had enough time to upgrade, now let's spend the > > time we save on things in our roadmap". > > Sure, but that's the thing. That is reactive, not proactive. > Consider the current 5.x -> 6.x situation again... What most people > who ask this stuff really want is, as soon as 6.0 is released, some > date when 5.x will become unsupported. But that is not something we > are ever going to do - it is impossible. Yeah, I guess you're right. We'll just have to live with that. > We are lucky in that we have a wonderful community, many of whom are > very helpful in the early shake out of these new releases. E.g., we > had a lot of testing and feedback of 6.0 well before it went Final. That indeed sounds very helpful. I wish that my company had the resources to help out with beta-testing... > > > As you plan moving to 6.0, definitely check out the Jakarta > > > Transformer to help automate some of the tedious Java Persistence > > > to Jakarta Persistence move. > > > > Thanks! I'm passing this on to our developers. > > They can also use the transformer config files Christian wrote for > our own migration efforts. Noted, thanks!
signature.asc
Description: This is a digitally signed message part
_______________________________________________ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
