[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 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@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 ___ 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
[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
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 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@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
[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
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
[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
On Wed, 2022-06-01 at 08:21 -0500, Steve Ebersole wrote: > > You can find our support policy here if you are interested: > > https://www.ciphermail.com/documentation/faq/support-policy.html > > That seems very similar to the one I wrote for Hibernate. I do see > now that ours is probably a bit unclear, specifically in terms of > how we view the different version components. I'll update that. Great! > The synopsis - consider the version x.y.z - > > 1. `x` is a major version which identifies a "significant" > change. The implications range from changes to external >contracts to removal of deprecated stuff to new features. Often >they will have limited backwards compatibility. > 2. `y` indicates new feature(s), which are not "disruptive" to > applications. All `y` for a given `x` are collectively called a >family. Within a family there will be compatibility - always at >the API level. And we strive to maintain compatibility at the >SPI (integration) level, though we do sometimes change these when >absolutely necessary. > 3. `z` includes just bug-fixes 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/ And so we try, but we can't always succeed. I imagine that this is a much harder problem to tackle for a project with such a large (and diverse) userbase as Hibernate. > Things we identify as incubating, internal, etc also affect this. > And in fact, with 6.0 I started to formalize this - see > https://docs.jboss.org/hibernate/orm/6.0/incubating/incubating.txt an > d > https://docs.jboss.org/hibernate/orm/6.0/internals/internal.txt > > But that still does not help with time frames per-se... That sounds like a good approach, dividing the codebase up allows you to maintain a different compatibility policy based on what part some piece of code belongs to. > > Thing is, somewhere in every release cycle, the Hibernate > > developers have to make a decision when they stop providing > > backported fixes. Right now that decision is made on an ad-hoc > > basis (if I'm not mistaken). > > Some well chosen words here ;) Heh, yeah, I am not the person working with Hibernate ORM in my organization, my colleagues and I don't know anything about how it's developed and so I have to resort to my limited understanding and assumptions... > * "~somewhere~ in every release cycle" - Well, not every release > cycle. As we transition to major versions that is true(ish). I > think that is what you probably meant, but just to be clear. Depends on your definition of a "major version" ;) 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". 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. > * "ad-hoc basis" - That is not the phrase I would choose necessarily, > but not far off. It is more that we do not know until we know. Take > 5.6 and 6.0... the elephant in the room there is the move from Java > Persistence to Jakarta Persistence, which is way out of our control. > But it has a major impact on applications.. Not all "EE" spec impls, > let alone libraries, have made that transition yet which puts > applications in a bind. Because of that it is impossible to give a > date when 5.x will no longer be supported. You are right. I think my suggestion to "just tell people when you are going to stop backporting fixes" was a bit shortsighted. That *is* hard to do in advance. As I mentioned in my previous email, we too had similar issues to consider and it took us many months to come up with some form of policy. I think that many people drag their feet on software updates, and will simply not perform the update unless they get an immediate benefit out of it. The addition of a specific feature that they desire is one such benefit, as is the availability of better (and current) documentation or other (support) resources. But I think the biggest driver for change is continued (security, bug) fixes, and the earlier they know when their current version stops receiving those, the earlier they update. This is largely how my organization goes about these things anyway. This has some overlap with human psychology. Someone should probably do a study on this. They could start with looking at what happened when
