What is the future plan regarding backwards compatibility?
I’m collaborating with several other writers who all currently use Dorico 2.1. When Dorico 3 comes out, will we all need to upgrade to continue swapping files?
And what about smaller releases? I notice that I get the message “this was created in version 2, updating to 2.1.” What’s the implication of this behavior in the future? Thanks.
PS: I don’t expect backwards compatibility to continue ad infinitum, just wondering what to anticipate budget-wise when next year’s paid update comes out.
We can’t promise that projects saved in future versions of Dorico will continue to be able to be opened by previous versions, though as of today you can open a project created in Dorico 2.1 in Dorico 1.0, with the obvious caveats that any data in the file that uses features added since Dorico 1.0 will not be handled; if you resave the project in Dorico 1.0 or another earlier version, then data related to features that the earlier version doesn’t understand will be removed from the file. So you cannot sensibly round-trip projects between the current version and an earlier version, though being able to at least open the project in an earlier version is hopefully useful on its own terms.
We cannot commit that we will never need to make a change to the project file format that would introduce a break in forwards compatibility, though our intention is to maintain this as long as it is practical to do so.
However, because round-tripping Dorico projects between different versions is inherently a lossy operation, I would strongly recommend that collaborators all use the same version of the product to avoid any nasty surprises.
Thanks for the reply, Daniel. I understand that in the long term we will definitely need to stay current with one another. In the short term, it’s a year-by-year prospect for us in regards to budget planning. Are you able yet to speculate on version 3 compatibility with 2.1 specifically?
My reason for asking is that, for everything we are working on currently, version 2.1 meets all of our needs. So while I will pick up the next paid upgrade, I may not update all of our site licenses if there is complete compatibility.
No, we’re not working on anything beyond the final 2.x update at the moment. As I say, we intend to keep forwards compatibility as part of the file format for as long as possible, and that includes next year’s paid update and hopefully beyond, but we can’t guarantee it.
In the long rung it would be good to have a commitment from Dorico regarding old scores. Claris Works is a frightening example. Suddenly ten years has passed and if you cannot open old scores and not downgrade there might be huge problems with old stuff, e.g. if you are to go into the work of a deceased composer. Of course this applies to all digital archives, I wish there was in insurance that you can get where your archives are upgraded for all future. There’s a business idea for someone <:-)
I doubt you’ll get any takers for your insurance idea. ClarisWorks was ended in 2007. If your app isn’t being developed, then you need to export all your data out of that app while it still works. Luckily, we have MusicXML now.
Opening old documents is one thing, and easily implemented. However, opening newer documents in older versions of the app is much harder – because you can’t know the future.
Finale manages to open the very first .mus documents, which is commendable. But you can’t open a 2012 document in Finale 2009. There are even problems with the newer .musx format. An app version before Dashed Slurs were introduced will convert all such slurs to normal ones when it saves.
You can rest assured that we do commit to always being able to open a project saved in an earlier version of Dorico in a later one. We cannot commit that the project will always appear exactly the same as it did in that earlier version in terms of layout etc. (e.g. even something as apparently simple as a modest change to Bravura could cause casting off to change), but that the musical data will be preserved.
That’s comforting Daniel, thank you.
A related question: Do you think it is advisable to make XML-exports from all old Logic and Sib scores as is today? Or is the future likely to increase the xml capabilities?
There are two parts to that question: (1) are the export capabilities from Logic and Sib going to improve, and (2) are the import capabilities of Dorico going to improve.
If your best guess about (1) is “no”, then you might as well export everything now, before something (e.g. an OS upgrade) suddenly stops them working. In any case, improved import will probably mean upgrading to a later version of Logic or Sibelius, which might cause other unexpected problems.
If you think (2) will improve (which would be my guess!) then don’t import the scores until you want to work on them.
I’m only concerned with safekeeping old scores, so, will the export qualities of Logic Pro X and Sib 7.1.3 (I will not upgrade) improve?
My guess is that nothing much will improve there, but is there a better guess than mine?
I can’t see that Sibelius’s export will improve, though you’ll get different results from Sib 7.1.3 if you use the (now free) Dolet plug-in to export MusicXML rather than the built-in export.
As to Logic Pro X, Daniel has previously mentioned that he’s in communication with Apple about some errors in the way that Logic exports MusicXML, so I guess there is a possibility that that could get better in future, if it’s a priority for Apple’s development team (which we can’t possibly know).
No software company devotes much (if any) effort to improving earlier versions of their products, so it’s a reasonable bet that Sibelius 7.x is now “frozen.”
Bear in mind that future updates to the Dolet plugin can only use the information that is available to it through Sibelius’s plugin-writing language. If a future version of Sibelius exposes more data and Dolet can use it to write a better XML file, that won’t benefit old versions of Sibelius.
I’ve no idea about the status of Logic - I’ve never used it.
Now I am confused again, said Bob Zavalaich at the Sib forum: “But Dolet is a plugin, and plugins have less access to Sibelius internals than Sibelius itself has, and so the built-in Sibelius exporter has at least the opportunity to produce better MusicXML that a plugin could provide.”
If this is valid still Sibelius own export should be preferred. Or?
I’m not a Sibelius guy, but I think Dolet is not a plug-in anymore, with the current version of Sibelius. It’s built-in. Sibelius uses Dolet now by default. …I think.
Edit: Nope. I should avoid commenting on Sibelius questions… sorry.
This is simply not the case, as has been stated on this forum before (by Daniel).
The Dolet plug-in was developed independently of Sibelius, and the Sibelius team later wrote their own export code.
In theory Sibelius’s own export code has access to bits of score information that Dolet doesn’t have, yet Dolet seems to do a better job in some cases.
Try both and compare the results. Dolet isn’t always better. Neither is Sibelius’s own export.
The Dolet plugin was written by the guy(s) who invented MusicXML, so they had a head start on how to use the data that they could get access to.
Everybody else had to use the documentation, and for the first release of MusicXML that was (cough) a bit like the documentation for the first release of Dorico
ClarisWorks was ended in 2007. If your app isn’t being developed, then you need to export all your data out of that app while it still works. Luckily, we have MusicXML now.