lasconic wrote
> 1- I agree that too short delays have consequences. However MuseScore has
> an update checker and it will nag users every week or so to upgrade to a
> more recent version. Also, I prefer having more user support to do with a
> simple answer (Please upgrade) than not having a good answer (Please wait
> for next version, release date: when it's ready).

Ok. (Incidentally, are we sure about the update notifier? I daily use 2.0
and have not been notified of 2.0.1 (yet?) ).

> 2- Backward and forward format compatibility needs to be defined... [...]
> As an example, files created in 2.0.1 can be open in 2.0, and files made
> in 2.0.2 should open in 2.0.1 and 2.0.

Good!

> If we have glissando playback in 2.0.2, there is no chance 2.0 or 2.0.1
> will play them... (are we still forward compatible then? I think so.)

I think so too. For me, forward compatibility means that scores created with
a later release can be open with an earlier one, without crash and with the
common elements having the same meaning. Of course, elements not existing in
the earlier release cannot be expected to be understood and rendered by it.

> Or another example, we used to create courtesy clef before a section break
> (bug #7886), if this is fixed in 2.0.2, a score created in 2.0.1 will look
> different in 2.0.2... and a score created in 2.0.2 will look different in
> 2.0.1. (are we still backward/forward compatible then? I think so.)

IIUC, a 2.0.2 score would look better in 2.0.1 than an original 2.0.1 one:
great! And yes, this is forward compatibility for me too.

> 3- Discussions are good but as you highlighted several times, there is no
> optimal solution for this problem.

Yet, non-100%-optimal solutions may range from 99%-optimal to 1%-optimal;
somewhere in between there is a threshold (there is a subjective element in
this, but it can usually be averaged).

> As we only store the "ornament style" and not the rendition, we can always
> make the style sounds better or add more style.

Indeed. But, once something is there and turns out below the aforementioned
threshold, we cannot any longer withdraw it, we are committed to bring it
above.

> In any case, we need an option to have no rendition at all, globally,
> since there will always be purists that would prefer to have nothing
> instead of something not "perfect".

Yes! ;-)

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Preparing-MuseScore-2-0-2-tp7579373p7579388.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Reply via email to