Yes, I am definitely in favor of this. My general feeling is, regular
releases are good, and in that I make little distinction between bug fix /
minor feature releases and somewhat larger undertakings like 2.1. I don't
mind if the 2.1-type releases are somewhat less frequent if there are
regular bug fixes in the interim. I think we've reached a point
feature-wise where increasing stabilty is more important than adding
features anyhow. As long as the bug fix releases don't interfere with
progress so much that 2.1 slips out another 2 years :-), I think this is
the right path to be on, and I'm glad to hear our processes seem to support
this.
My only concern is in tracking which bugs affect which releases, and which
fixes have been applied to which. I've been attempting to track this in my
"hit list", but it requires constantly supervision and manual intervention
to make it happen. I have thought a little about how we could improve
things.
I propose we try to keep to only one one active trunk and one active branch
at all times, although the "active branch" may change from "2.0" to "2.1"
once 2.1 is released and the master starts moving toward 2.2. Or at most,
maybe at some point we branch 2.1 *before* it is release, so that work can
commence on 2.2. So there might be a master, a "next semi-major release"
branch, and a "next bug-fix release" branch.
With that model, I would like to see the Issue Tracker enhanced to record
which branches a bug applies to. Whether there are two or three "active
branches" (counting the master), I'd want something like the current
"Status" field for each. If this were literally tied to the branch ID on
GitHub, hopefully we could have the same sort of automation so that merging
a fix on a particular branch would update the status for that branch in the
tracker. When a bug is submitted, the user should be allowed to say what
version the bug report is applied too, with choices that are meaningful to
the user - like "2.0", "2.0.1", "Nightly build", "Current master". This
could be mapped automatically to a branch ID, but realistically, we are
going to more and more finding situations where bugs need manual
confirmation. Eg, bugs submitted against 2.0 that were already fixed in
2.0.1 or are fixed in nightly builds, etc. So we might consider having
bugs be submitted in an "Unconfirmed" state with respect to one or more of
the branches, and require explicit action from someone who understands all
this to actually mark it either active or fixed for branches other than one
it was reported against.
I have no idea how feasible that is. I thought about ways of handling this
just with tags in the issue tracker, and that is probably doable if more of
us had the abiltiy to add / remove tags. We could simply have tags
"ActiveIn2.0", "FixedIn2.0", "ActiveInMaster", "FixedInMaster", and perhaps
at some point "ActiveIn2.1" etc.
I imagine this a problem that other projects need to solve as well, but
when I look at, for instance, the trackers for Qt or LibreOffice, I see
things that seem less useful. Or maybe I just don't understand them.
Marc
On Tue, May 19, 2015 at 10:41 AM, Joachim Schmitz <j...@schmitz-digital.de>
wrote:
> 1- Why not just using the 2.0 branch? 2.0.1 is taged there, so can
> get recovere0d
>
> 4- I believe that if you’d drop the ‘-noobsolete’ from the command
> generating the translation sources, those could server 2.0m 2.0.1, 2.0.2
> and 2.1, all at the same time? Could switch it on again when 2.1 gets into
> Beta or RC status.
>
>
>
> Bye, Jojo
>
>
>
> *From:* Lasconic [mailto:lasco...@gmail.com]
> *Sent:* Tuesday, May 19, 2015 4:13 PM
> *To:* MuseScore
> *Subject:* [Mscore-developer] Preparing MuseScore 2.0.2
>
>
>
> Hi,
>
>
>
> We released MuseScore 2.0.1 a couple of weeks ago. Apparently users were
> delighted to have a bugfix release after MuseScore 2.0. Since then, we
> already have several bug fixes and even some new features. The initial plan
> was to wait for 2.1 somewhere in the fall and not make more bugfix release
> but somehow it's easier than expected to maintain the master branch and a
> release branch. It might delay 2.1 a bit but at least users get small
> updates faster.
>
>
>
> So I would like to propose the following.
>
>
>
> 1 - Create a 2.0.2 branch based on the (badly named) 2.0 branch
> https://github.com/musescore/MuseScore/tree/2.0. We used this branch for
> 2.0.1 release in fact.
>
>
>
> 2- Cherry pick as many bugfixes and features we can with two goals: bring
> value to users and avoid regressions and format incompatibilies.
> Development would still happen on master for 2.1. Cherry picking can
> include freetype and Jim Newton's work on midi rendering.
>
>
>
> 3- Switch nightly builds to use this 2.0.2 branch in order to test the
> next release
>
>
>
> 4- Switch on the translation workflow again on the 2.0.2 branch. It means
> 2.0 and 2.0.1 will not receive any translation updates anymore and only
> 2.0.2 would get the new translations. For this reason, I would wait a
> couple of weeks before doing so. We could investigate a way to only add
> strings to transifex and then upload translations for both version... but
> it might be overkill.
>
>
>
> I would like to target end of June, beginning of July for MuseScore 2.0.2
> release.
>
>
>
> lasconic
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Marc Sabatella
m...@outsideshore.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
