| My suggestions are pretty simple: 1. Provide milestone and release candidate builds to be able to identify issues before the rest of the world is left having to work around them.
2. Don't break binary compatibility in a minor release. According to semver, I should be able to run my application that was on Hibernate 5.1 on Hibernate 5.2 without any need for recompilation.
3. Don't raise JVM requirements in minor versions. I cannot take my Java 6 or 7 application running on Hibernate 5.1 to run Hibernate 5.2. This is clearly something for a major release.
4. Make sure you have sufficient test coverage to prevent fundamental JPA functionality to break. I am kind of surprised to see that with sort of every release something breaks in the mapping information detection. Converters being reported invalidly, identifiers not being discovered anymore etc. Just couple of minutes ago I got another bug filed mentioning Hibernate 5.2 and it turns out a simple lookup on the JPA CriteriaBuilder is broken that works on 5.1 (see
 HHH-10870 New ). Those points seem to be very trivial and fundamental aspects of software development, and I wonder how you can actually build something minimally reliable at all, if you neglect those. Actually, the Spring Data team tracks Hibernate builds and releases [very closely|https://travis-ci.org/spring-projects/spring-data-jpa| with build profiles set up for all the versions and snapshot flying around. However, since 5.0 we sort of suffer from the broken window syndrome, as we're basically running from one bug into another. I just subscribed to the developers mailing list a few weeks ago and will happily share my opinion going forward, in case questions like these should come up again  . |