Happened to be doing my morning email purge and this luckily came in at just that time :D
On Wed, Jun 1, 2022 at 7:32 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > Hi Steve, > 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. 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 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 and https://docs.jboss.org/hibernate/orm/6.0/internals/internal.txt But that still does not help with time frames per-se... 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 ;) * "~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. * "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. 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. _______________________________________________ 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
