[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
On Thu, 2022-06-02 at 11:52 -0500, Steve Ebersole wrote: > Let me know what y'all think - > https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team Looks really good! Like I said in my previous email, it is good to see the public/private API distinction documented. The 'qualifier' being sortable is also nice, hadn't noticed that. In theory, if our developers haven't used any 'internal' or 'incubating' stuff in their code, then I guess that the 6.0 -> 6.1 update (and all future updates until 7.0) should be a drop-in replacement for us. That would be awesome. signature.asc Description: This is a digitally signed message part ___ 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 Thu, 2022-06-02 at 07:37 -0500, Steve Ebersole wrote: > > 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. Well I did not say that you "could never fix bugs", just that a bugfix has a certain probability of being a breaking change for some user out there. As your userbase grows, that probability approaches 1. Semantic Versioning actually recognizes this issue: in the introduction, the authors state that for SemVer to work, you must first declare a public API, then communicate changes to it using the version number. That way, a "backwards-compatible bugfix" is truly backwards compatible for users that strictly implement your public API. From what I've seen in the documentation, it looks like Hibernate now has a clear distinction between the public and private API (you describe this in "Huge Project, Small Team" [1]). So, kudos :) [1] https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team#internal > > 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. Yeah, I guess you're right. We'll just have to live with that. > 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. That indeed sounds very helpful. I wish that my company had the resources to help out with beta-testing... > > > 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. Noted, thanks! signature.asc Description: This is a digitally signed message part ___ 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
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
[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
Happened to be doing my morning email purge and this luckily came in at just that time :D On Wed, Jun 1, 2022 at 7:32 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > Hi Steve, > 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. 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 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 and https://docs.jboss.org/hibernate/orm/6.0/internals/internal.txt But that still does not help with time frames per-se... 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 ;) * "~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. * "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. 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. ___ 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
Hi Steve, Thanks for the kind reply, I'm glad we could clear things up a bit. I felt quite bad about the miscommunication and have been blaming myself for it. On Tue, 2022-05-31 at 11:48 -0500, Steve Ebersole wrote: > Before I was lucky enough to get paid for working on Hibernate, I > worked on it in my free time. Congratulations on managing to get paid for developing free and open- source software, that is no small feat! We too have a FOSS community edition of our product, but the lion's share of the work is being done in the proprietary enterprise extensions that bring in the money for us. > But we used it at the company I worked for at the time. I often > ended up using custom builds, though generally that was more > "forward facing" as I generally wanted features or fixes I was > working on that were maybe not ready for a community release. > > I also have done it with projects that I was not part of the > development of. In fact, I still do as I had to do some of this > with the move to Jakarta EE and the fact that not all of the > libraries we use were updated for Jakarta at the time. > > So I have done it. As do many others. Not arguing, it's just an > interesting topic. I'm familiar with the practice of modifying FOSS so that a feature for internal (company) use can be implemented. We do that as well with some projects. It always turns out to be harder than expected to properly upstream the changes, and unfortunately we don't manage to do it often. Also sometimes a change you make is so specialized that upstream has no use for it, and neither party benefits. Sometimes you just have to maintain the internal fork. > Many developers I think also shy away from this with Hibernate > specifically because of FUD over the LGPL. Tell me about it. We have recently started a review of our license compliance, to see if we still meet all our obligations towards the licensors of the FOSS we use. This is quite hard for the small company I work for. I am the IT ops guy, but now I do legal as well. Lots of FUD indeed. > > (If it isn't clear by now, I am a big proponent of updating > > software in a timely manner instead of feet-dragging until you > > drown in "upgrade debt".) > > Awesome! I like the phrase too! Thanks :) Now I wish that all our (CipherMail) users would have a similar attitude. Despite our efforts, not everyone is on a version that we provide active support for. I think you feel the same with Hibernate. We are actively encouraging our users to keep upgrading, mostly by making upgrading as simple as reasonably possible, writing upgrade guides, discussing upgrade strategies with customers and helping our users to plan their upgrades with a support policy. You can find our support policy here if you are interested: https://www.ciphermail.com/documentation/faq/support-policy.html > I put the X there deliberately. It is not at all my place to make > > decisions on this; how long users of older versions should > > receive bugfixes, and indeed if they should receive updates at all, > > is something that only the Hibernate developers can decide on. > > But that's the problem. There is not a hard and fast rule. There > is no single 'X'. Only a Sith thinks in absolutes ;) I joke (my > daughter and I were watching some Star Wars last night, so just fresh > in my mind). Haha :) If it makes you feel any better, we didn't have anything like the support policy linked above for a long time. The result was that we made all kinds of promises to customers that were in hindsight either too vague or too hard to keep. Writing down this support policy was no easy task and caused quite a bit of internal discussion (also with our support and sales partners), but in the end we are still very glad that we did. > Maybe a better solution would be to somehow earmark this on the > release pages. E.g. https://hibernate.org/orm/releases/5.4/. > Maybe a new "status" in addition to "development" and "stable". I am > not the website guru though so that is something the team would need > to discuss. > > It does not alleviate the "when" aspect, but honestly I do not > foresee that happening. Too many variables and we are generally too > busy doing actual development. > > Open to suggestions though. I can relate to the "many variables" part. 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 releases get backported fixes for a much longer time than other releases. And that's fine, but because there is no support intention written down anywhere, it will cause people to speculate about those intentions. As I explain below, that speculation can be a bit dangerous. >> https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team > > Ah, thanks! I thought I had written that down, but could not find > it :D > > We have a slightly
[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
On Tue, May 31, 2022 at 11:18 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > > I think the reality is that people who use software that has been > declared end-of-life by their suppliers often don't backport it > themselves. I've unfortunately seen enough cases of this happening... Before I was lucky enough to get paid for working on Hibernate, I worked on it in my free time. But we used it at the company I worked for at the time. I often ended up using custom builds, though generally that was more "forward facing" as I generally wanted features or fixes I was working on that were maybe not ready for a community release. I also have done it with projects that I was not part of the development of. In fact, I still do as I had to do some of this with the move to Jakarta EE and the fact that not all of the libraries we use were updated for Jakarta at the time. So I have done it. As do many others. Not arguing, it's just an interesting topic. Many developers I think also shy away from this with Hibernate specifically because of FUD over the LGPL. (If it isn't clear by now, I am a big proponent of updating software in > a timely manner instead of feet-dragging until you drown in "upgrade > debt".) > Awesome! I like the phrase too! I put the X there deliberately. It is not at all my place to make > decisions on this; how long users of older versions should receive > bugfixes, and indeed if they should receive updates at all, is > something that only the Hibernate developers can decide on. > But that's the problem. There is not a hard and fast rule. There is no single 'X'. Only a Sith thinks in absolutes ;) I joke (my daughter and I were watching some Star Wars last night, so just fresh in my mind). The uncertainty comes from not knowing whether the Hibernate release > someone is using will receive backported fixes or not. I did not mean > to extrapolate that to all users. Maybe I should have put "uncertainty > among some Hibernate users" there as I do not in fact know whether many > users experience this uncertainty. However, I am not the first one to > voice this uncertainty, so it is not just *my* uncertainty either: > Maybe a better solution would be to somehow earmark this on the release pages. E.g. https://hibernate.org/orm/releases/5.4/. Maybe a new "status" in addition to "development" and "stable". I am not the website guru though so that is something the team would need to discuss. It does not alleviate the "when" aspect, but honestly I do not foresee that happening. Too many variables and we are generally too busy doing actual development. Open to suggestions though. I just noticed the backporting information linked to in that second > forum thread, here: > https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team Ah, thanks! I thought I had written that down, but could not find it :D We have a slightly different definition of version naming though it follows the semantics of semantic versioning. 6.1 has new features, so strictly following semantic versioning it should be named 7.0. So sure, we could rename 6.1 to 7.0 and have these "nonsense major versions", but really what does that gain anyone? Anyway, that's all to say I still cannot give you a date. I can say probably not before the end of summer. 5.6 is interesting because there is one consumer (Quarkus) currently using it that we want to support. But they have not yet made the move to Jakarta so cannot use 6.x yet. For what it is worth... ___ 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
Hi Steve, I have a feeling that there is a slight misunderstanding here, for which I'm sorry. Please allow me to clarify some things. On Tue, 2022-05-31 at 07:31 -0500, Steve Ebersole wrote: > The reality is that we are a very small team - it is simply not > feasible to maintain that many branches[1]. Of course. I myself work in a small team as well, I know that it is really hard to support old software versions. We hardly offer extended support to our own users as well. > [1] Though really, point me to any project / product the size and > complexity of Hibernate, not to mention user base, that supports as > many code bases for free that you are asking. I am not asking that at all. Sorry if it seemed that way, it was not at all my intention. I can imagine that Hibernate developers sometimes receive demanding requests from users who want free long-term support. I despise that, and I am well aware of the fact that the company I work for uses Hibernate under a gratis license, without any warranty whatsoever. Also, I have a lot of respect for people who put their spare time in a free- and open source project (as does the company I work for). > You are not asking about "time to upgrade" anyway, in my opinion. > You are asking about removing the need to upgrade, which is very > different. No! I am not asking that at all! I am just trying to manage the expectations of my team members and helping them to upgrade to Hibernate 6 in a timely manner. At the same time I am trying to provide some feedback to the Hibernate developers. > Us stopping support for 5.6 does not mean you can no longer use > 5.6. It simply means we (this very tiny team) will no longer back- > port changes. > You can continue to use it; and in fact, since it is open source, > you can even continue to do these back-ports yourself. I think the reality is that people who use software that has been declared end-of-life by their suppliers often don't backport it themselves. I've unfortunately seen enough cases of this happening... (If it isn't clear by now, I am a big proponent of updating software in a timely manner instead of feet-dragging until you drown in "upgrade debt".) > As for a statement on the website, I'm not sure exactly what that > would look like. Your suggestion is just vague. "X months"? How > many months is that? 2? 24? Big difference. I put the X there deliberately. It is not at all my place to make decisions on this; how long users of older versions should receive bugfixes, and indeed if they should receive updates at all, is something that only the Hibernate developers can decide on. > E.g., you realize 6.0 was released exactly 2 months ago to the day > right[2][3]? That is "months" already. And I have already said we > will continue to support 5.6 for the time being, so that will be > "months"++. The rest of your statement is in fact exactly what we > do already[4]. I'm not against adding something to the website if > it helps clarify things, but that wording is not it. > [2] https://in.relation.to/2022/03/31/orm-60-final/ > [3] That was 6.0.0.Final. Including CR releases (which I do) its > been many, many months. > [4] 6.0 has been out for months. 6.1 is about to be released. And we > are still supporting 5.6. Sure. I'm not making any demands here. It is great that 5.6 will still receive updates for some time. My suggestion is just that the Hibernate developers put some statement on the website regarding what to expect in terms of backporting. The text I provided was just an example. If you would say that Hibernate devs would stop backporting fixes for 5.6 tomorrow, then I can make a compelling case to my colleagues that they should prioritize the upgrade to 6.0, meaning that we would upgrade earlier. But right now there is no such statement at all, meaning that it is hard to make this case, which results in us not deciding on prioritizing our upgrade. I hope this makes sense. > P.S. To be fair, by "reduce doubt among Hibernate users" you mean > *your* "doubt". Which is fine, but let's not extrapolate that to > all Hibernate users. Sorry, I think the word 'uncertainty' instead of 'doubt' would have been the better choice. English is not my first language... The uncertainty comes from not knowing whether the Hibernate release someone is using will receive backported fixes or not. I did not mean to extrapolate that to all users. Maybe I should have put "uncertainty among some Hibernate users" there as I do not in fact know whether many users experience this uncertainty. However, I am not the first one to voice this uncertainty, so it is not just *my* uncertainty either: - https://discourse.hibernate.org/t/hibernate-orm-versions-end-of-life-details/6354 - https://discourse.hibernate.org/t/end-of-life-hibernate/2772 I just noticed the backporting information linked to in that second forum thread, here: https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team However, the
[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading
The reality is that we are a very small team - it is simply not feasible to maintain that many branches[1]. You are not asking about "time to upgrade" anyway, in my opinion. You are asking about removing the need to upgrade, which is very different. Us stopping support for 5.6 does not mean you can no longer use 5.6. It simply means we (this very tiny team) will no longer back-port changes. You can continue to use it; and in fact, since it is open source, you can even continue to do these back-ports yourself. As for a statement on the website, I'm not sure exactly what that would look like. Your suggestion is just vague. "X months"? How many months is that? 2? 24? Big difference. E.g., you realize 6.0 was released exactly 2 months ago to the day right[2][3]? That is "months" already. And I have already said we will continue to support 5.6 for the time being, so that will be "months"++. The rest of your statement is in fact exactly what we do already[4]. I'm not against adding something to the website if it helps clarify things, but that wording is not it. P.S. To be fair, by "reduce doubt among Hibernate users" you mean *your* "doubt". Which is fine, but let's not extrapolate that to all Hibernate users. [1] Though really, point me to any project / product the size and complexity of Hibernate, not to mention user base, that supports as many code bases for free that you are asking. [2] https://in.relation.to/2022/03/31/orm-60-final/ [3] That was 6.0.0.Final. Including CR releases (which I do) its been many, many months. [4] 6.0 has been out for months. 6.1 is about to be released. And we are still supporting 5.6. ___ 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 Mon, 2022-05-30 at 09:35 -0500, Steve Ebersole wrote: > There is not a hard date. Not in the immediate future is the best > I can say at the moment. Thanks for your reply, Steve. It would be nice if 5.6 continues to receive bugfixes for some time. That would allow us to further validate our recent update to 5.6 and prepare for the upgrade to 6.0 (or 6.1 when it's out). I can't find any statement on the Hibernate ORM website on this topic, but I see that 5.2 hasn't had updates since November 2018, while 5.3 received an update only last month. That would suggest that 5.3 is still somewhat supported. I understand from beikov's comment on the Hibernate forum that this is because of a commercial offering: https://discourse.hibernate.org/t/hibernate-orm-versions-end-of-life-details/6354/2 Would it be an idea to publish a policy on the website that clearly describes how long one can expect bugfix updates after a new release? I imagine this would help Hibernate users to plan their upgrades, and also serves as an encouragement to keep up with Hibernate releases, potentially preventing some people from keeping unsupported versions in use. Something like "The Hibernate developers strive to support each Hibernate release series for X months after a newer series has been released, to allow Hibernate users some time to upgrade". I think this would also reduce doubt among Hibernate users regarding the support status of the versions they have in use, as well as reduce "update fatigue" by allowing users to better plan their updates, and allow the Hibernate developers to save some time responding to questions like mine on the forum and mailing list ;) Anyway, thanks for considering. Imre signature.asc Description: This is a digitally signed message part ___ 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
There is not a hard date. Not in the immediate future is the best I can say at the moment. On Mon, May 30, 2022 at 3:54 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > Hi there, > > We're very excited about the Hibernate ORM 6.0 release! Our developers > have looked at upgrading our copy from 5.6 to 6.0, but they consider > 6.0 "not yet stable enough" (no idea if that's justified) and have had > some issues with the upgrade guide. They estimate the upgrade to take > about ten man-days. That's all the feedback I have right now, > unfortunately. > > We want to schedule our upgrade to Hibernate 6 ideally before the > Hibernate developers stop backporting bug fixes to the 5.x branches. > Could you make a rough prediction when that would be, so that we and > others looking at Hibernate 6 can schedule their upgrade? > > Thanks a lot, > > -- > Imre Jonk > IT Automation Engineer > CipherMail B.V. > > ___ > 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
