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