Release cycles after 2.0

• Jan 5, 2015 - 18:52
S5 - Suggestion

I'm not sure if there is already a discussion going on about this, but I would like to express my opinion and encourage others to do the same.

As everyone can see, there have been tons of great improvements since development for 2.0 started three years ago. The problem is that only power users could see what was going on by testing the nightlies. For your regular "I use what's released" user, it looked as if nothing happened for three (or at least two since 1.3) years.

By following the old mantra "release early, release often", MuseScore might become more visible. With the manpower you have, a release cycle like the 2.x Linux kernels might be a reasonable idea. This way, bugfixes and small improvements could go into 2.0.x, while the cool (and possibly unstable) stuff goes to 2.1.x until it is considered stable enough to be called 2.2.0 and so on.

I'm curious what others think about this...


This is more suited as a forum discussion; it's neither a "bug" nor a "feature request". I think in general, you'll find general agree we should be releasing more often after 2.0. It's just the enormity of what went into 2.0 that caused it to take so long.

Status (old) closed active

It's an interesting discussion, but it would have been better suited on the forum instead of the issue tracker. So I will close this issue. Also, I doubt any user would disagree on getting new stuff more often, so not sure if time wouldn't be better spent on finding and fixing bugs instead...

I think you are overestimated the manpower we have. MuseScore is mainly developed by 6-7 max. See to get a better overview. There were 389 developers involved in the release 2.6.11, it was the lowest number of all versions of the kernel. (Source: Also note that MuseScore 1.3 has been released "only" 2 years ago. While indeed 2.0 development started more than 3 years ago.

However, I understand what you mean, and we will do our best to have 2.X releases more often by limiting the number of new features and concentrate on fixing bugs. It was already the case for the 1.X releases. See
"Release early, release often" is exactly what we do with "nightly builds" (which are not nightly anymore for over a year now but created for each commit)

Given the above, I disagree on the two tracks approach you are describing. If MuseScore 2.0 is so "late" it's because we kept working on the 1.X and 2.X tracks together so long. So, I will do all I can to enforce a single track (2.1, 2.2 etc...) with a mix of (little) cool stuff and a lot of bug fixes. With our small human power, it's the only way to go to get more new versions of MuseScore more often.

I agree that this should probably have been a forum post. However, I suppose more people are currently watching the issue tracker, so the topic should get more attention here.

I'm far from suggesting that MuseScore has a manpower comparable to the Linux kernel - any project would dream of that. I was just looking for a release model that ensures stability and active development at the same time. The old Linux model seems to suit smaller development teams better than the current one. In many cases, a bugfix commit would probably apply to both branches successfully.

Whatever it will be, I suggest documenting the release plans on the website - even if these plans are not going to be met every time. Waiting tends to be easier if you know if you're going to wait days or months.

Just a note: So far, from 2.0 through 2.0.2, there's been a release every other month. What I'm wondering is what it would take for a future version to ever claim the title "MuseScore 3"—there were some very significant new features in 2.0.2, and even that wasn't enough to qualify bumping up the number even to 2.1. What conceivable changes would be big enough to ever make it all the way to 3.0?

We've set the bar pretty high indeed. Both in the sheer number of changes that went into our first major new release (from 1.3 to 2.0), and how many changes went to 2.0.2 without calling it 2.1. We've established a precedent that even a "minor" release (2.0 to 2.1) needs to be pretty big, and a major release is enormous. But there is no law forcing us to adhere to that. And note both Finale and Sibelius have changed their release strategies multiple times over the years. As has many other companies.

Speaking just for myself, I think it is as relevant to talk about *compatibility* issues as *feature* issues.

One thought that might make sense for now is, anything that breaks forward compatibiltiy - so scores created with the new version can't be opened with the last - needs at least a minor release bump. We went out of our way to make sure 2.0.2 scores could still be opened in 2.0.1 ot 2.0. Which isn't to say we *couldn't* have called it 2.1, but we didn't *need* to by this measure.

A major release bump might mean not only are the scores not forward compatible in that sense, but you might expect to have some backwards compatibility issues as well, with older scores perhaps not rendering the same or having some limitations, to the extent that it might make sense to keep both versions installed at once.

A few things off the top of my head that might cause a major release bump by virtue of likely effect on compatibilty but also happen to seem like "big deals" that might "deserve" a major release bump even if not for compatibility:

- Google-Docs-like collaborative editing
- integration of the mobile apps to allow editing on any device
- radically new input system like handwriting or real time MIDI
- radically new playback system
- a major reorganization of the layout algorithms for better performance as well as to allow more / better automatic placement of elements and collision avoidance

A problem with having chosen to use such tiny differences in release numbers has occurred to me. The Handbook.

There are currently two separate Handbooks on this site. One is "for MuseScore 2.0 and above"; the other is "an archived Handbook written for MuseScore 1." It's clearly necessary to keep around the old documentation for the old version—otherwise the Handbook would simply have been updated and there would be no "archived" documentation available. The question is, what about the future?

Already, the Handbook "for MuseScore 2.0 and above" includes occasional information that in reality only applies to MuseScore 2.0.*2* and above. At the current rate, it seems clear that there will be a great many significant differences between MuseScore 2.0 and the future MuseScore 2.1. With so many differences, it might seem like a good idea to maintain an "archived" 2.0 Handbook, as well. (This may be something the developers have already thought about.) The thing is, once, it might have been reasonable to say "all releases of the 2.x series will have one Handbook, and the 3.x series will get a new Handbook"—but with the bar set so very high for 3.0, it is probable that for many years in the future every new version of MuseScore (with who is to say how many enormous and significant changes and new features?) is going to start with a 2. So where do you draw the line? It's not so clear anymore. And wherever the line is drawn, it's not going to be so appealing as a simple "1, 2, 3" division of Handbooks anymore.

"This is an archived handbook page written for MuseScore 2.0 through 2.0.3. Navigate to the handbook page for MuseScore 2.1 and above."

Now I'm seeing that there is, indeed, a 2.0.3 branch (which I'm guessing would probably be better named 2.1.1). Is it premature to guess that the developers are planning, essentially, that MuseScore is going to be MuseScore 2 for a very long time—similar to the way what was once Mac OS has been OS X (i.e., OS Ten) since 2002?

I created the 2.0.3 branch, just in case we need to release a 2.0.3 version. Meaning a small update to 2.0.2 to solve any critical issue.
The current plan as explained here… is to work on MuseScore 2.1.

As Marc explained, the main difference between a 2.0.3 release and a 2.1 release would be that files created with 2.1 wouldn't be readable with MuseScore 2.0.x. At a given moment we nee to break this compatibility if we want to add more features.

MuseScore 3 is not planned as of today.

Regarding the handbook. It's perfectly fine for me to have a current handbook for 2.0.x even if if some documented features are not part of of MuseScore 2.0.0 or MuseScore 2.0.1. MuseScore 2.1 is far enough on the horizon to not have to worry about the handbook yet but my first feeling would be to keep on using the current handbook too. In any case, we don't have to decide now since none of these versions are released. So let's make the best documentation we can for the current version of MuseScore, MuseScore 2.0.2.