On Mon, 2022-05-30 at 09:35 -0500, Steve Ebersole wrote: 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-deta... 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

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: 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. 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). 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. 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".) 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. 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. 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-deta... - 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 information in that wiki article is now outdated, and also doesn't seem to reflect the current practice of the Hibernate developers. (it also speaks about 4.1, 4.2 and 4.3 being "major" releases, while the convention is that these point releases are called "minor" releases: https://semver.org/).

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: 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. 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. 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. 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 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. 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 Version numbering is often regarded as black art. Did you know about this quirk related to the versioning used for the Linux kernel project? "Does the major version number (4.x vs 5.x) mean anything? No. The major version number is incremented when the number after the dot starts looking "too big." There is literally no other reason." https://www.kernel.org/releases.html#does-the-major-version-number-4-x-vs... What I'm trying to say is, it seems there are many competing version numbering "standards". Some have heated discussions over what the numbers are supposed to mean, or which scheme a project should use. We adhere to SemVer because we needed to use _some_ scheme, but in reality that whole debate is largely a distraction. You use what you think is best. Please don't go through the trouble of renaming 6.1 to 7.0 just because I commented on it in my previous message... Okay this is something! Now I can tell my colleagues that they should aim to upgrade before the end of summer, which means that we can prioritize this. We'd rather not wait to see you guys stop supporting it because your customer did manage to upgrade in the meantime. To give some perspective: I just told my boss and he was surprised. He had made the (dangerous, if you ask me) assumption that Hibernate 5.6 would be supported for a few more years. Now that he and I both know that the Hibernate devs aim to stop 5.6 support in a few short months, there is a strong and almost immediate benefit in prioritizing our upgrade. We know that there are no guarantees. We cannot demand that you support 5.6 longer. What we can do however, is try to factor in the intentions of the Hibernate developers. If you guys say that you don't want to support 5.6 for a long time, than that is a very clear signal to us that we should get to work. Maybe there are other Hibernate users out there that made the same assumption as my boss. I hope that they'll find this thread and reconsider their upgrade planning. I'm glad that people like you work on Hibernate. Take care. Imre

On Wed, 2022-06-01 at 08:21 -0500, Steve Ebersole wrote: Great! 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. 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. 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... 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. 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 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). Thanks! I'm passing this on to our developers. Imre

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&gt; wrote:

On Thu, 2022-06-02 at 11:52 -0500, Steve Ebersole wrote: 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.