[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
Christian Beikov <[email protected]> Thu, 2 Jun 2022 20:38:45 +0200
| Newsgroups | gmane.comp.java.hibernate.devel |
|---|---|
| Message-ID | <[email protected]> |
Looks great, thanks for writing that up! Am 02.06.2022 um 18:52 schrieb Steve Ebersole: > Let me know what y'all think - > https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team > > On Thu, Jun 2, 2022 at 7:37 AM Steve Ebersole <[email protected]> wrote: > >> I think we generally agree and understand each other here. >> >> >> On Thu, Jun 2, 2022 at 6:32 AM Imre Jonk via hibernate-dev < >> [email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ hibernate-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s