@Jojo
1- Because branch are cheap and it feels right to have a branch per
release. It's the same model Qt has for example.
4- We could try to remove no-obsolete. However, MuseScore 2.0 and MuseScore
2.0.1 are currently downloading translation files from different
directories. My plan was to create another directory for 2.0.2 but then we
could use the 2.0 one... In any case, the transifex to S3 process will need
to push to 2 or 3 directories.
@Marc
My plan was indeed to have only 2 branches active. A next release one and
the master branch.
Regarding the issue tracker, we still need to talk it through with Thomas
but I think it could be solved with a combination "Affects Version(s)" and
"Fixed version(s)" like in Qt. I'm not sure if the Drupal issue tracker we
use offer this.
Changing the link between github and musescore.org is possible. The message
sent by gihub contains the branch so we could add a message when the bug is
fixed on master and another message when the bug is fixed in a branch.
@Maurizio
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).
2- Backward and forward format compatibility needs to be defined... The
plan is still to always be backward compatible in bugfix/minor release and
from one major release to another (2.0 to 2.1). If forward compatibility
means that an older version can open a more recent version file but will
miss some features then I believe we can also do it for bugfix/minor
release. 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.
But, both backward and forward compatibility have limits given the way
MuseScore works currently. 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.) 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.)
If we answer No to both questions then it greatly limits the scope of fixes
we can do...
3- Discussions are good but as you highlighted several times, there is no
optimal solution for this problem. As we only store the "ornament style"
and not the rendition, we can always make the style sounds better or add
more style. 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".
lasconic
2015-05-20 10:44 GMT+02:00 Maurizio M. Gavioli <miwa...@miwarre.org>:
> First of all, I have no suggestions on the maintenance points.
>
> About the main topic, FWIW I also believe that bug fixes are always
> welcome!
> With a few notices:
>
> 1) Users do not always care (or even know) about product versions (many do
> not even care about which OS they use...). I assume that 'power users' or
> /aficionados/ who look every week for a new release are the minority.
> Multiplying the releases increases user support (obsolete bug reports,
> ...).
>
> In the past, there has been too much delay between releases; but even too
> short delays have consequences.
>
> 2) I would value backward *and forward* file format compatibility across
> all
> 2.0.x releases (I would value it even across all 2.x.x releases, but this
> probably asking too much).
>
> I now have a largish corpus of scores to maintain and I am still in the
> process of upgrading all of them to 2.0 (which is currently taking most of
> my free time). From my experience, I assume that everybody else who
> routinely uses MS to circulate scores among a community (of students, of
> choir singers, or whatever) would see his life made more complex by a
> multitude of not 100% compatible releases, rather than simpler.
>
> 3) Jim's work on ornaments is to be praised. If possible, I would really
> appreciate to see some things about Baroque ornaments 'optimized' before
> releasing it to the general public. There are discussions going on on that.
>
> Thanks,
>
> M.
>
>
>
> --
> View this message in context:
> http://dev-list.musescore.org/Preparing-MuseScore-2-0-2-tp7579373p7579380.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
>
------------------------------------------------------------------------------
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
