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
