Corruption on delete of initial timesig if section break present with no subsequent timesig
Reported version
2.2
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
1) new score, 3/4
2) add section break to bar 4
3) delete initial timesig (results in first four bars turning into three bars of 4/4, which is correct)
4) save
5) reload
Result: corruption starting in bar 4
The rewrite of the bars stopped at the section break. It needs to continue past the section break up to the next timesig, just as it would if you deleted a non-initial timesig.
Comments
The bug is in 2.2, maybe even older, not a regression in 2.3
Indeed. Are we officially changing the meaning of the "Version" field? I personally recommend against this. Having a permanent record of the version the bug was actually reported against - updated only to reflect the earlier relevant version it is known to affect - is hugely valuable. We don't want to lose that. Moment to moment mind-changing about which version we might try to fix it in is better suited for tags, IMHO.
In reply to Indeed. Are we officially… by Marc Sabatella
As a user and contributor to the MuseScore forums, it is much easier to help someone if I know which versions which bugs were first reported in and which version it is fixed for. There was just a user who posted a score using 2.0.3. There are some features and bugs that were fixed in version 2.1 and 2.2.1. I should be able to look at the issues and see if anything that user is talking about has changed between the older and current version. I and many of us, have been doing this long enough that we remember having seen an issue but don't remember when. The issue tracker should be able to answer all of our questions. Making all open issues reported until now version 2.3 obscures this.
From talking to and watching programmers it is clear that narrowing down an issue to a specific piece of code is easier if it is known which version the bug was introduced in. I allows them to search only code that was changed between that and the previous version. Once again, changing every bug to version 2.3 obscures this. It is a very bad idea. If you are concerned about which bugs and features were added to version 2.3, there is a Git message telling to which branch each PR is merged with.
Thank you for your opinions! Sure, let's keep the version meaning as it has been existing for years. What do you think about the process of specifying the most valuable issues that are good to be fixed in the next minor release? Is priority field enough?
Well, this gets to the topic you raised on the forums recently. I do feel some better structure is in order here. But I continue to believe there is an important difference between severity and priority. Sure, most critical issues are high priority, but some that are not critical may also be, and that's worth tracking separately. Still, maybe I'm the only one who cares about that. Tags to specify the release we'd like to target for a fix make perfect sense and are way better I think than manually tracking "hit lists".
Corruption happens only in terms of incorrectly placed rests. If you start writing notes, everything works as expected.
![Screenshot 2018-11-13 at 18.41.05.png]( "Screenshot 2018-11-13 at 18.41.05.png")