Should the next version be 3.2 or 4.0?

[mdgood]

One topic we discussed at the Community Group online meeting was whether the next version of MusicXML should be 3.2 or 4.0. We didn't come to consensus, so let's get some feedback by discussing in this issue.

Arguments for version 3.2 include:

• The proposed additions are mostly smaller-scale items that seem more in line with a minor release than a major release.
• Calling it 3.2 helps keep focus on MNX-Common.
• Using 3.2 is more in line with semantic versioning.

Arguments for version 4.0 include:

• Features like improved parts support and machine listening are worth a major version number.
• By the time we release it will have been 9 years since MusicXML 3.0; it's time for a new major version.
• We have never had a MusicXML x.2 release; version 4.0 is better for marketing.
• Our work on MNX-Common, with the example and software-based approach that Adrian is driving, will let us develop both projects in parallel without one detracting from the other.
• Semantic versioning is intended for APIs, not data formats like MusicXML that never introduce breaking incompatibilities with older versions.

What are your thoughts? Are there points on either side that are not captured here?

[adrianholovaty]

I think that captures the pros and cons nicely. Can't think of anything else to add to either side.

Personally I'm ambivalent about the decision — I'm cool with either one.

[bhamblok]

I like to move forward, so for that reason + all other reasons mentioned by Michael, version 4.0 sounds better to me.
PS: I apologise for not having attended the Community Group online meeting. I really regret that something came up (at work), I should have taken the day off... Well ... next year!

[jsutdolph]

3.2 if I'm forced to choose. But I don't really care. it's only a number!

[JDLH]

I prefer 3.2, because I think it conveys a clearer meaning through semantic versioning.
I would not veto 4.0, especially if parts support was pitched as the leading innovation in the new version. The message would something like "MusicXML has parts support, which takes us to a new major version, 4.0. But we maintained backwards compatibility!'
But on the other hand, I do not place a great weight on marketing MusicXML. It has its niche of partial-fidelity interchange. It will not expand beyond it. MNX and MEI are the candidates for becoming formats for digital scores. That is what I consider worth marketing.

[samuelbradshaw]

Have public-facing release notes been prepared? Reviewing the full list of changes that will be marketed (so to speak) might help in the decision.

[JDLH]

"Semantic versioning is intended for APIs, not data formats like MusicXML that never introduce breaking incompatibilities with older versions." I disagree with this argument. A format specification like MusicXML is similar to, not different from, an API. Both define an interface by which independent entities can exchange information and collaborate. In both cases, the interface can change in a way that breaks compatibility with previous versions, preserves compatibility but extends, or fixes bugs without extending or breaking compatibility.
If new versions of MusicXML are going to ensure that old documents remain compliant with the new spec (I think we call that "backwards compatibility", though jargon differs) that is great. It is also a reason to make this visible by keeping the major version number unchanged.
The Document Format (PDF) is perhaps comparable. It was published as PDF-1.0 in 1993, then went through 7 revisions to PDF-1.7 in 2006. It preserved backwards compatibility with existing documents, and left the major version number unchanged. PDF moved to version 2.0 in 2017, 24 years after version 1.0. There is no shame at preserving compatibility and preserving a major version number.

[mscuthbert]

My preference is for 4.0 (but it's not something I'm super passionate about, unlike MNX-[...] naming) -- the main reason is that it shows the vibrancy of the notation community that two different W3C standards (+ MEI and others) can be in active development at the same time.

I like 4.0 also because it shows the beginning of two new features -- links parts are just in their infancy, so we can have 4.1, 4.2, 4.3, etc. to develop that further.

We've never had an X.2 release is the only argument I didn't find compelling. Almost an argument to do one.

But let's let 4.0 be the start of doing a release a year. :-)

[jsawruk]

I agree with @mscuthbert: I am leaning towards 4.0, but not I'm not super passionate about it either. I think it really comes down to how significant the changes are. Using 4.0 might indicate either significant enhancements and/or breaking changes. I don't think we have any breaking changes, so it really comes down to how significant the enhancements are. Personally, I think the enhancements are worthy of a 4.0, but I can also see how others might feel they are only worthy of a 3.2.

[mdgood]

@samuelbradshaw We don't have public-facing release notes yet, but you can see the list of issues planned here: https://github.com/w3c/musicxml/milestone/2

[mdgood]

Similar to the online meeting, there is a narrow majority in favor of 4.0 without a lot of strong feeling one way or the other. We will go with 4.0 then.

I have updated the milestone to 4.0. I will soon create an initial pull request to update the version number, copyright notice, and license. We will move back to the W3C Community Contributor License Agreement during the development process.