@lasconic: Is there a plan of the features planned to be included / developed for MuseScore 2.1?
Another question: if we keep two branches "next release" and "stable release", which will be the target of the PR? If we take the Qt model as an example: they have a "tree" of branches and they suggest to file PR for bug fixing to the "outermost layer" and they periodically merge these changes to the development branches. Sometimes this is tricky, because at some point the innermost branch is frozen for/after the release and a PR is then proposed for the just-above branch, but then if the PR discussion goes on, a new outer branch for the next release can be created and at that point the PR is for the parent branch and not the outer branch and therefore, when merged, it will be part of the release after the next one. [This is what actually happened for a fix for 64bit Windows I pushed to Qt before "5.4.1" was branched when branch "5.4.0" was accepting only critical patches (so I pushed it to parent branch "5.4"), which did not manage to get merged for Qt 5.4.1, but will be present in Qt 5.4.2 ] At the moment in MuseScore PR are made to the "next release" branch and cherry picked to the "stable release" branch. Are we continuing this way? -- View this message in context: http://dev-list.musescore.org/Preparing-MuseScore-2-0-2-tp7579373p7579384.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 [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
