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 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? 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-5-x-mean-anything 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... > 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... 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
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
