Hi Stefan, On the general question of deprecating features and breaking changes: I think we should simply stick to SemVer of the released artefacts to signal those changes to upstream.
On the more specific topic of session behaviour: could we use session attributes to let the app specify session behaviour? [1] And on the very specific topic of auto-refresh: yes, this was introduced to ease application transition onto Oak. I agree if conflicts conceptually with MVCC. However: is there an actual problem with the auto-refresh behaviour? Cheers Michael [1] https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Session.html#getAttribute(java.lang.String) On 28/07/16 10:23, "Stefan Egli" <[email protected]> wrote: >Hi, > >Here's an idea that just came up in an offline discussion, not sure if it >has been around elsewhere. But we could introduce a concept of >'compatibility levels' which are a set of features/behaviours that a >particular oak version has and that application code relies upon. When >creating a session by default the 'newest compatibility level' would be >used, but applications could opt to use an older, compatibility level 1.2 >for example, when they still rely on the feature-set/behaviour oak had at >that time. (This could also be based on service-user properties for >example.) As such, compatibility levels could be a vehicle to help properly >deprecate features over time (when you'd say eg oak 1.10 doesn't support >compatibility level oak 1.0 anymore). > >One concrete case where this could have been useful is the >backwards-compatible behaviour where a session is auto-refreshed when >changes are done in another session. This seems counter-intuitive given >MVCC, but was apparently introduced to remain jackrabbit-2-compatible. > >(Another slightly different example could be the warn about a session being >open for too long without a refresh. This is likely an oversight from an >application, but it could also be done on purpose (although I wouldn't know >an example right now) - in which case this could be indicated via another >flag on the session - but probably doesn't quite fit the compatibility-level >approach). > >Opinions? > >Cheers, >Stefan > >
