[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