7:31 a.m.
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...
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