On 2016-07-28 10:23, Stefan Egli 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).
...
/me very skeptical
Reasons:
- people copy stuff like that into their code without understanding what
it means
- the versioning would be extremly coarse-grained
- this may result in having to maintain older behavior for much longer
Best regards, Julian
