I think we generally agree and understand each other here.
On Thu, Jun 2, 2022 at 6:32 AM Imre Jonk via hibernate-dev <
hibernate-dev(a)lists.jboss.org> wrote:
This sounds a lot like how we do our version numbering as well. We try
to be as backward-compatible as possible with new "y" (minor) and
particularly the "z" (patch) releases, and try to put all the breaking
changes in the "x" (major) releases. 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.
Depends on your definition of a "major version" ;)
Yep, we are back to words being important :D
I've already documented here what we consider a major version and its
implications; so you know my definition.
> 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.
I now see the end-of-life warnings on the 5.0, 5.1, 5.2, 5.4 and 5.5
> release pages! Did you just add those? They are great! I think this
> gives a very clear signal to anyone still using those versions that
> they are now quite overdue on their updates.
We discussed it and Yoann added that stuff. Thanks Yoann!
This has some overlap with human psychology. Someone should probably do
> a study on this. They could start with looking at what happened when
> Python 2's end-of-life date was finally announced... (you are probably
> well aware, but if not: everyone was dragging their feet until the
> announcement, which caused an enormous acceleration in the Python 3
> transition).
Not a Python developer[1], so not really familiar with that specifically;
but it is a common enough situation in software development. It also
probably meant that Python 3 was not as thoroughly tested as it could have
been prior to that accelerated migration.
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.
> 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[2].
[1] I had to develop in Jython for almost a year once and REFUSE to ever do
anything Python related ever again ;)
[2]
https://github.com/hibernate/hibernate-orm/tree/ff9e9eebc9992c7bc9128e9bf...