[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
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 <steve(a)hibernate.org> 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 <
>> 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...
>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s