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#...
> 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!