Re: [hibernate-dev] Compatibility Considerations wiki

Hi Steve, Thanks for writing up these rules. That's very valuable information for users and us as well. Only two remarks on the following: oftentimes. In which cases is it not granular enough? Can such case not always be circumvented by refactoring code into separate classes within separate packages? I'm fearing issues with e.g. distinguishing between public (API/SPI) vs. internal parts on a finer level than the package, as that's what OSGi but also JBoss Modules rely on. We cannot fully leverage the ability of these module systems to "hide" internal parts of a module in that case. Also I think annotations are easier to "miss" than package names when importing classes into an application, thus I'm concerned about accidental referencing internal classes. necessarily across different release families. A specific example, similar to the API section, would be nice, e.g.: "If you implement an application against an integration point from Hibernate ORM 4.3.0, the expectation is that it works without changes when updating to ORM 4.3.1. It should also continue to work when updating to ORM 4.4.x in the very most cases, but that's not guaranteed." --Gunnar 2014-08-09 16:55 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: