Preparing MuseScore 2.0.2

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Preparing MuseScore 2.0.2

lasconic
Administrator
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Jojo-Schmitz

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:[hidden email]]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Marc Sabatella
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 <[hidden email]> 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:[hidden email]]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer




--
Marc Sabatella
[hidden email]

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Maurizio M. Gavioli
In reply to this post by lasconic
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.
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

lasconic
Administrator
@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 <[hidden email]>:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
ABL
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

ABL
@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?
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

lasconic
Administrator
A plan for 2.1. Yes, sort of. More a plan for the next two or three major releases. I still need to publish it on musescore.org. Also, the plan is to adapt if someone is motivated enough to work on something that we didn't think about.

I like to refer to the Qt project but I also understand we are a lot lot smaller. So far, pulling into master and cherry picking in the bugfix branch worked out for 2.0.1, so I would keep the same model for 2.0.2. For 2.0.1, I did the cherry picking and I'm ready to do it for 2.0.2 as well.
So, yes, I think we can keep on developing and making PR on master.

lasconic

2015-05-20 12:47 GMT+02:00 ABL <[hidden email]>:
@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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Maurizio M. Gavioli
In reply to this post by lasconic
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
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

lasconic
Administrator

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

Yes, the update notifier works well on Windows and Mac. I test it for every release.
It's completely disabled on Linux and BSDs since it's the role of the package management system on each platform.
Unfortunately, 2.0.1 is not packaged for many Linux distribs yet.

 
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.
 
Not in this case, since the clef is hidden during layout.


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Maurizio M. Gavioli
lasconic wrote
Yes, the update notifier works well on Windows and Mac. I test it for every release.
It's completely disabled on Linux and BSDs since it's the role of the package management system on each platform.
Oh, I see, this explains everything. Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Leon Vinken
In reply to this post by lasconic
Just checking, "bug fixes only in 2.0.x" seems to imply we will keep using the MusicXML DOM parser in 2.0.x and switch to the pull parser in 2.1. Correct ?

Note that I am not too happy about that, as it implies double work (especially for me) on fixing MusicMXL import issues for quite some time. On the other hand, it does not seem like the pull parser has had a lot of test coverage yet and when we switch I would like to have a testing period of at least one to two months where all the nightlies use the pull parser. If we would want to switch for 2.0.2, I think now would the time to do it.

Regards, Leon.
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

lasconic
Administrator
Hi Leon,

I didn't assume anything for the pull parser. So it's open.

I gather that you are willing to have more tests on the pull parser, so yes we could put it in the 2.0.2 branch and enable it by default if you think it's best way to go.

Nicolas

2015-05-28 21:17 GMT+02:00 Leon Vinken <[hidden email]>:
Just checking, "bug fixes only in 2.0.x" seems to imply we will keep using
the MusicXML DOM parser in 2.0.x and switch to the pull parser in 2.1.
Correct ?

Note that I am not too happy about that, as it implies double work
(especially for me) on fixing MusicMXL import issues for quite some time. On
the other hand, it does not seem like the pull parser has had a lot of test
coverage yet and when we switch I would like to have a testing period of at
least one to two months where all the nightlies use the pull parser. If we
would want to switch for 2.0.2, I think now would the time to do it.

Regards, Leon.




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

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

Leon Vinken
Indeed, my preference would be to switch over to the pull parser by default a.s.a.p., to get broader test coverage. I have done all the testing I could think of, now I need additional testers to find the corner cases I forgot.

Regards, Leon.
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

lasconic
Administrator
I created the 2.0.2 branch but I changed my plan a bit. I was going to cherry pick the vast majority of the commits of master so I figured out it was be better to branch master and remove what we didn't want. So here is what I did.

1/ I created 2.0.2 branch based on master
2/ I talked with Werner and on IRC, I talked with Marc, Jojo, to find out the changes we did that would make files created in 2.0.2 not look right in MuseScore 2.0 and 2.0.1. We found a couple of things 
* storage of irregular measure and breakMMRest property in measure is done differently in master
* Master uses the new met* symbol from the last version of bravura in tempo texts. 2.0 and 2.0.1 don't have this symbol.
3/ I made changes in the 2.0.2 branch to solve these two problems. If you can think of anything else, or if you find a file made in nightlies that don't open correctly in 2.0/2.0.1, please report.
4/ I changed the version to 2.0.2 in the code.

Starting from today, nightlies on Mac and nightlies on Windows are built from the 2.0.2 branch. It would be great if Linux nightlies could use this branch too.

Regarding translations, I reactivated the push to Transifex and I removed the -noobsolete flag when calling lupdate. Transifex should get the strings added in the 2.0.2 branch and keep deleted strings. However we might have deleted some strings between 2.0 and 2.0.1...
The process in charge of getting strings from transifex and store them for the resource manager has also been updated and now store the strings in two folders, one for 2.0.1 and one for 2.0.2. Since we could have removed strings for 2.0 I didn't do anything yet, so 2.0 will not receive translations updates for now.

Leon, the 2.0.2 branch is based on master. So the pull parser is on by default.

The addition of this branch doesn't change the development process. The master branch is still the reference, we should use it to make PR. I will monitor the commits and cherry pick them in the 2.0.2 branch until the release. The goal is still end of june, beginning of July.

lasconic

2015-05-29 7:13 GMT+02:00 Leon Vinken <[hidden email]>:
Indeed, my preference would be to switch over to the pull parser by default
a.s.a.p., to get broader test coverage. I have done all the testing I could
think of, now I need additional testers to find the corner cases I forgot.

Regards, Leon.



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

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

robert leleu
D'accord pour compiler 2.0.2
Je joins mon script.....je ne comprends pas comment le moidfier pour récupérer la 2.0.2
Robert Leleu


Je la 06/06/2015 23:54, Lasconic skribis :
I created the 2.0.2 branch but I changed my plan a bit. I was going to cherry pick the vast majority of the commits of master so I figured out it was be better to branch master and remove what we didn't want. So here is what I did.

1/ I created 2.0.2 branch based on master
2/ I talked with Werner and on IRC, I talked with Marc, Jojo, to find out the changes we did that would make files created in 2.0.2 not look right in MuseScore 2.0 and 2.0.1. We found a couple of things 
* storage of irregular measure and breakMMRest property in measure is done differently in master
* Master uses the new met* symbol from the last version of bravura in tempo texts. 2.0 and 2.0.1 don't have this symbol.
3/ I made changes in the 2.0.2 branch to solve these two problems. If you can think of anything else, or if you find a file made in nightlies that don't open correctly in 2.0/2.0.1, please report.
4/ I changed the version to 2.0.2 in the code.

Starting from today, nightlies on Mac and nightlies on Windows are built from the 2.0.2 branch. It would be great if Linux nightlies could use this branch too.

Regarding translations, I reactivated the push to Transifex and I removed the -noobsolete flag when calling lupdate. Transifex should get the strings added in the 2.0.2 branch and keep deleted strings. However we might have deleted some strings between 2.0 and 2.0.1...
The process in charge of getting strings from transifex and store them for the resource manager has also been updated and now store the strings in two folders, one for 2.0.1 and one for 2.0.2. Since we could have removed strings for 2.0 I didn't do anything yet, so 2.0 will not receive translations updates for now.

Leon, the 2.0.2 branch is based on master. So the pull parser is on by default.

The addition of this branch doesn't change the development process. The master branch is still the reference, we should use it to make PR. I will monitor the commits and cherry pick them in the 2.0.2 branch until the release. The goal is still end of june, beginning of July.

lasconic

2015-05-29 7:13 GMT+02:00 Leon Vinken <[hidden email]>:
Indeed, my preference would be to switch over to the pull parser by default
a.s.a.p., to get broader test coverage. I have done all the testing I could
think of, now I need additional testers to find the corner cases I forgot.

Regards, Leon.



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

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

mscoremaj (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

lasconic
Administrator
Add 

git checkout 2.0.2

before
git reset --hard HEAD
git pull

lasconic


2015-06-07 14:38 GMT+02:00 Robert Leleu <[hidden email]>:
D'accord pour compiler 2.0.2
Je joins mon script.....je ne comprends pas comment le moidfier pour récupérer la 2.0.2
Robert Leleu


Je la 06/06/2015 23:54, Lasconic skribis :
I created the 2.0.2 branch but I changed my plan a bit. I was going to cherry pick the vast majority of the commits of master so I figured out it was be better to branch master and remove what we didn't want. So here is what I did.

1/ I created 2.0.2 branch based on master
2/ I talked with Werner and on IRC, I talked with Marc, Jojo, to find out the changes we did that would make files created in 2.0.2 not look right in MuseScore 2.0 and 2.0.1. We found a couple of things 
* storage of irregular measure and breakMMRest property in measure is done differently in master
* Master uses the new met* symbol from the last version of bravura in tempo texts. 2.0 and 2.0.1 don't have this symbol.
3/ I made changes in the 2.0.2 branch to solve these two problems. If you can think of anything else, or if you find a file made in nightlies that don't open correctly in 2.0/2.0.1, please report.
4/ I changed the version to 2.0.2 in the code.

Starting from today, nightlies on Mac and nightlies on Windows are built from the 2.0.2 branch. It would be great if Linux nightlies could use this branch too.

Regarding translations, I reactivated the push to Transifex and I removed the -noobsolete flag when calling lupdate. Transifex should get the strings added in the 2.0.2 branch and keep deleted strings. However we might have deleted some strings between 2.0 and 2.0.1...
The process in charge of getting strings from transifex and store them for the resource manager has also been updated and now store the strings in two folders, one for 2.0.1 and one for 2.0.2. Since we could have removed strings for 2.0 I didn't do anything yet, so 2.0 will not receive translations updates for now.

Leon, the 2.0.2 branch is based on master. So the pull parser is on by default.

The addition of this branch doesn't change the development process. The master branch is still the reference, we should use it to make PR. I will monitor the commits and cherry pick them in the 2.0.2 branch until the release. The goal is still end of june, beginning of July.

lasconic

2015-05-29 7:13 GMT+02:00 Leon Vinken <[hidden email]>:
Indeed, my preference would be to switch over to the pull parser by default
a.s.a.p., to get broader test coverage. I have done all the testing I could
think of, now I need additional testers to find the corner cases I forgot.

Regards, Leon.



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

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: Preparing MuseScore 2.0.2

robert leleu
works
thanks

Je la 09/06/2015 14:52, Lasconic skribis :
Add 

git checkout 2.0.2

before
git reset --hard HEAD
git pull

lasconic


2015-06-07 14:38 GMT+02:00 Robert Leleu <[hidden email]>:
D'accord pour compiler 2.0.2
Je joins mon script.....je ne comprends pas comment le moidfier pour récupérer la 2.0.2
Robert Leleu


Je la 06/06/2015 23:54, Lasconic skribis :
I created the 2.0.2 branch but I changed my plan a bit. I was going to cherry pick the vast majority of the commits of master so I figured out it was be better to branch master and remove what we didn't want. So here is what I did.

1/ I created 2.0.2 branch based on master
2/ I talked with Werner and on IRC, I talked with Marc, Jojo, to find out the changes we did that would make files created in 2.0.2 not look right in MuseScore 2.0 and 2.0.1. We found a couple of things 
* storage of irregular measure and breakMMRest property in measure is done differently in master
* Master uses the new met* symbol from the last version of bravura in tempo texts. 2.0 and 2.0.1 don't have this symbol.
3/ I made changes in the 2.0.2 branch to solve these two problems. If you can think of anything else, or if you find a file made in nightlies that don't open correctly in 2.0/2.0.1, please report.
4/ I changed the version to 2.0.2 in the code.

Starting from today, nightlies on Mac and nightlies on Windows are built from the 2.0.2 branch. It would be great if Linux nightlies could use this branch too.

Regarding translations, I reactivated the push to Transifex and I removed the -noobsolete flag when calling lupdate. Transifex should get the strings added in the 2.0.2 branch and keep deleted strings. However we might have deleted some strings between 2.0 and 2.0.1...
The process in charge of getting strings from transifex and store them for the resource manager has also been updated and now store the strings in two folders, one for 2.0.1 and one for 2.0.2. Since we could have removed strings for 2.0 I didn't do anything yet, so 2.0 will not receive translations updates for now.

Leon, the 2.0.2 branch is based on master. So the pull parser is on by default.

The addition of this branch doesn't change the development process. The master branch is still the reference, we should use it to make PR. I will monitor the commits and cherry pick them in the 2.0.2 branch until the release. The goal is still end of june, beginning of July.

lasconic

2015-05-29 7:13 GMT+02:00 Leon Vinken <[hidden email]>:
Indeed, my preference would be to switch over to the pull parser by default
a.s.a.p., to get broader test coverage. I have done all the testing I could
think of, now I need additional testers to find the corner cases I forgot.

Regards, Leon.



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

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



------------------------------------------------------------------------------


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer




------------------------------------------------------------------------------


_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer