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@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/ff9e9eebc9992c7bc9128e9bf33d4b51b2bee7a4/rules _______________________________________________ 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
