I put 3.3-beta in the recycle bin
and it will stay there until
- It stops changing the layout of my palettes in 3.2.3
- It stops crashing when I try to adjust my palettes
- It stops crashing on startup because the last edit was to a custom workspace. I won't do another factory reset to start it.
Comments
I was also expecting a good bug-fix release with great hopes.
We've come across a version that has been destroyed by someone's palette/workspace design.
This kind of innovation may be in half versions(x.5) or Major (X.0) versions.
But it should be kept completely separate from bug-fix versions.
In reply to I was also expecting a good… by Ziya Mete Demircan
Well a bug fix only version would have been called 3.2.4 right?
semver 3.3 means new functionalities but compatible with the 3... family.
In reply to I was also expecting a good… by Ziya Mete Demircan
I think you may have the wrong idea about the release numbering. 3.3 is not a "bug fix" release, that would have been "3.2.4". Bumping the minor number is exactly the right thing for a release that is essentially similar to previous releases but introduces significant features, especially if they are not fully backwards compatible. A new improved (once the bugs are fixed obviously) palette design plus the other listed changes is perfectly consistent with the idea of bumping the minor version.
In reply to I think you may have the… by Marc Sabatella
How is it like that:
Recommendation: Use half or Major versions for radical changes.
And don't put Major-changes and bug-fixes together. Keep them separate.
You may still not understand it, but I'm tired.
Make some effort to understand.
In reply to How is it like that:… by Ziya Mete Demircan
I understand what you are suggesting, I think, I'm just saying, that's not how it is currently done, nor is it how most software works. The changes in this release are nowhere near big enough to justify a major release. And the problem with half releases is you only get one before you have to change to a major release, plus it looks weird and random to skip (3.0, 3.1, 3.2, 3.5? what's next, is this a Fibonacci series?). I much prefer the more common model of simply using minor numbers for things like this.
I agree major changes don't go into big fix release, but this isn't a bug fix release. I don't think you are suggesting that changes that include major release shouldn't also fix bugs - I've never in my life seen such a thing - but if you are, then I do disagree with that.
In reply to I understand what you are… by Marc Sabatella
No, I'm saying, "bugfix versions should be made."
Where are the bug-fix versions?
Where is 3.2.4, and/or up?
Palette and UI change was made at 3.3.x; OK.
There was no bugfix release before that. <= !
Musescore x.x.Y versions usually use it as an emergency-release version, right?
So I'm not the one who invented something new. I speak according to the current situation.
Wouldn't a 3.2.4 version be good before this palette/workspace change?
And now we're dealing with palettes and other bugs, rather than a version that fixes some bugs.
>(3.0, 3.1, 3.2, 3.5? what's next, is this a Fibonacci series?)
Really? Fibonacci versions? <= Are you mocking?
It's time for me to step back.
In reply to No, I'm saying, "bugfixes… by Ziya Mete Demircan
I'm confused. 3.2.1, 3.2.2, 3.2.3 - those were bugfix releases. We had three of them, then a minor release that includes some new features as well as bug fixes. This is all completely normal, I'm truly mystified as to what you find unusual about this, or why you feel there would be any particular need for yet another bugfix release before moving to 3.3. Is four the magic number of bugfixes you always expect before a minor release? If we did a 3.2.4 first, why would that seem any better a time to move to 3.3 rather than after 3.2.3? I'm honestly completely confused here.
Not sure what you mean about "emergency-release" version, either. Sure, a couple of bug fix releases were made very quickly to fix super-critical problems, but they are still bugfix releases like any other. I think 3.2.1 was that way, I think 3.0.4 or 3.0.5 also.
Sorry if my joke about Fibonacci series was lost in translation :-). The point is, I think it looks very odd to have minor releases skip numbers. All it does is make me wonder what happened to the interim releases. So if I see 3.1., 3.2, then 3.5, I wonder what happened to 3.3 and 3.4 (did I somehow miss them?), and also wonder what would be next. To me skipping numbers is a bad idea.
Anyhow, this is just a beta, and yes, clearly, the new palettes have some bugs that will obviously need to be fixed before the real release. This is all, again, perfectly normal - except that I would agree the basic crashy-ness of the new palettes (on Windows at least) makes this beta seem perhaps premature. But if so, that's just an issue with the timing of the beta, not with the release numbering.
In reply to How is it like that:… by Ziya Mete Demircan
MuseScore is using the semver standard way to assign version number.
That standard is not "one standard among other ones" but really recognized as "the" reference in the software world.
So really no reason to invent a "MuseScore way" here.
I understand the feeling, the new code is unfortunately pretty unstable still, at least on Windows. I have little doubt the crashes will be resolved soon, so hopefully we can all resume normal beta testing (right now it won't run under debugger at all for me, so I'm no help with the crashes).
As for changing the layout of palettes in 3.2.3, I'm not totally sure what you mean there. You made reference to that elsewhere, but you might want to list specific steps. I meant, if you try to load a 3.2.3 workspace then edit it, I guess I might expect those edits to be seen in 3.2.3, although since so much about the palette design has changed, I wouldn't necessarily expect the modified palette to make sense. I'd just expect to have different custom workspaces, one set for 3.2.3, a different set for 3.3 And this works just for me as far as I can tell. Are you saying it doesn't for you - that editing a 3.3. workspace in 3.3 causes changes to 3.2.3 workspaces you didn't modify.
In reply to I understand the feeling,… by Marc Sabatella
_As for changing the layout of palettes in 3.2.3, I'm not totally sure what you mean _
Spend 2 hours setting up you custom workspace in version 3.2.3, Make any adjustment whatsoever to the 3.3 beta. Open 3.2.3 and see all of your work undone. It doesn't get any clearer than that.
In reply to _As for changing the layout… by mike320
I'm sorry, it's still not clear to me. Are you saying:
1) you created a new workspace in 3.2.3 (we'll call it "new_323_workspace")
2) you customized that workspace in 3.2.3
3) you then opened 3.3 (while leaving 3.2.3 open? or not?)
4) you then somehow selected the "new_323_workspace" (or not?)
5) you then closed 3.3 (or not?)
6) you then reopened 3.2.3
For me, when I follow those steps, all works as I expect - 3.2.3 still shows my "new_323_worksapce" selected, and it still contains my modifications.
Or are you just saying that customizations made in 3.3 aren't seen in 3.2.3? That is the way development buids always work, for workspaces, shortcuts, preferences, everything - they are saved to a MuseScore3Development folder to avoid trashing your regular working environment. Aside from that, it is also important to close MuseScore successfully in order for workspace changes to be saved.
In reply to I'm sorry, it's still not… by Marc Sabatella
Update: I may be seeing something different from you because I am not actually running the beta (which doesn't display palettes at all for me, for some reason) but my own build. I gather the beta does share settings with 3.2.3, so I could indeed imagine customizations to a workspace in 3.3. clobbering things for 3.2.3. I'd suggest simply not doing that - create a separate workspace for your 3.3 customizations.