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
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
