Hi, > 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.
My defensive side feels that doing compatibility type feature is harder to maintain than to implement. Primary point being that such cross cutting configurations affect code flows at arbitrary places. That along with linear growth of compatibilities would, imo, be harder to test and certify (to think at unit level, it might still work out with really going rigorous with parametrized tests... but doing ITs specially on stuff like part of repo was done at vX and run with compatibility at vY... is vZ still ok with it?). I think being server side (enterprisey??), oak does have a small luxury of relying on acceptance testing type of processes with hard deprecations/removal/changes. I mean, I understand the requirement for such cases... but we should probably don't add a feature for this... a hack to remain backward compatible (e.g. session refresh due to apps used to relying on jr2) should probably treated as such and removed going forward with a blunt hammer. And, even if we don't remove this, this should probably just remain as limited hack-specific thing. Thanks, Vikas
