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
