I enjoyed reading another of Axel’s blog posts. Confusingly there is a link allowing comments, but comment submission is currently impossible since a needed spam filter is offline ATM.
I would have added nothing new, but just repeated the old point that there are for sure some architects’ and infrastructure persons’ objections against breaking backwards compatibility since change requires work on their end; at the same time overly complex interfaces might cause confusion for large parts of ROOT’s userbase which are most often not experts (“real physicists”) and whose productivity might similarly suffer because it takes a lot of time to learn to do things The True ROOT Way.
I also tried to comment but was foiled by the “try again later” message.
My comment was about the idea of making ROOT 6 a fork of ROOT 5. The team could continue to fix bugs in ROOT 5 but provide no new features (and could backport compatible fixes from ROOT 6), then ROOT 6 could be free to break whatever backwards compatiblity is required to overhaul the system. This is exactly how Python made/is making the transition from 2->3.
For Python, many users are able to run their old Python 2.X scripts as Python 3 without much modification. The only big change is needing to convert their print statements into print function calls using the 2to3.py converter, which is trivial. I think most end-users would not need to change their ROOT scripts much to make the transition to some non-compatible ROOT 6, while big experiments who do care about the gritty details could continue to use ROOT 5 for a while.
Avoiding breaking compatibility is a good thing up to a point, but after that point it becomes “well we’ve always done it this way!”
For ROOT 6 we are indeed not tying ourselves to strict backward compatibility (for example we are not planning on supporting all of CINT features, especially not the un-intentional ones ). However we also try to carefully selecting what we do continue to support and what we do not. We are also intentionally not introducing any change not related directly to the change from CINT to cling in order to simplify our testing task (if the same ‘code’ work in both v5 and v6 we can more easily check that the behavior has not changed). We also want to simply the framework’s transition work (same thing the less they have to change from v5 to v6 the easier it is to validate). Once ROOT 6 is out of the door, it will be the time to thing about real interface changes.
). However we also try to carefully selecting what we do continue to support and what we do not. We are also intentionally not introducing any change not related directly to the change from CINT to cling in order to simplify our testing task (if the same ‘code’ work in both v5 and v6 we can more easily check that the behavior has not changed). We also want to simply the framework’s transition work (same thing the less they have to change from v5 to v6 the easier it is to validate). Once ROOT 6 is out of the door, it will be the time to thing about real interface changes.