Back-compatibility
If I understand correctly (I noticed recently), a score created in a later version within series 2 can be opened in an earlier one, but I have reservations about this.
I’m sure any commits will have been carefully considered (as to not break anything), but could it not introduce a different set of problems?
For example, a non-savvy user may not realise they are using a newer file in an older version, or the potential discrepancies (causing confusion).
If this practise continues into series 3, would we have to wait until series 4 for certain improvements (not referring to major code) that could be implemented in the branch of the previous?
I don’t think we should be sacrificing the opportunity of progressing a series. If an older version is required, then MusicXML, though not as good, is probably more suited for this purpose.
If there is still an insistence on back-compatibility, is it possible to introduce a courtesy message for the user?
Comments
For the most part, when we say a score opened in any given version within the 2.x series will also open in an earlier version, we mean it will do so *without* the sort of "potential discrepancies" that could possibly cause confusion. There are only a very small number of very minor exceptions I know of to this where we decided some new capability was important enough to be worth the very small risk of very slight confusion in the very unlikely case someone did this.
However, there will definitely *not* be any expectation that scores created in MuseScore 3 will be openable in MuseScore 2. Just as MuseScore 2 files can't be opening in 1.x. So I don't think there is anything in particular we would need to wait to MuseScore 4 to include. Might be plenty of things that don't make the cut into MuseScore 3, but it wouldn't be for compatibility reasons.
In reply to For the most part, when we by Marc Sabatella
And the only thing I know of here is (de)crescendo lines, available in 2.0.3 but not before and there's shown as hairpins
In reply to And the only thing I know of by Jojo-Schmitz
Also, from 2.1 to earlier, there will be #121051: Multimeasure rests should account for fermatas.
In reply to Also, from 2.1 to earlier, by Isaac Weiss
Does that change the mscz file Isaac? That sounds like a 2.1 display algorithm.
In reply to Does that change the mscz by mike320
No, but like the cresc./dim. dashed lines, it's something that if used will appear differently in older versions.
In reply to No, but like the cresc./dim. by Isaac Weiss
yeeaahhh...2.0.2 just never looks at the spot where the words appear on the hairpin so it doesn't realize that it's changing the display. The fermata display is actually an improvement from 2.0.3 to 2.1 without changing the file. 2.1 is not tricking earlier versions, it's doing something better.
I'm still not convinced.
I remember seeing a layout difference (the system jumped) between the 2.0 release candidate and a later stable version; I'm concerned whomever will encounter such issues if opening in an older version.
In reply to I'm still not convinced… by chen lung
Well, sure, sometimes a bug fix means something might look different between versions. This is to some extent unavoidable, but indeed we do think long and hard about whether a given bug fix is actually worth it if it does cause any noticeable change. To the extent it only causes problems with scores that relied on unwise use of manual adjustments, it's easier to say it's OK.
In any case, it isn't clear what your concern actually is here. Are you suggesting we should never fix bugs if there is any chance at all it will affect layout of any score in any way?
In reply to I'm still not convinced… by chen lung
Side note: Being "compatible" doesn't mean being "exactly equal".