Draft versioning / ETA for a v1.0?

[Danielku15]

Hey folks.

I had MNX now on the radar for quite a while and I planned to add support for it in my music notation library (alphaTab). I love the semantic mindset of MNX (compared to the rather visually oriented formats in the market), it fits well the mindset in my project.

The main reason for not adapting the format yet, was the undefined pre-release nature of the format. MNX is still very actively designed/developed towards a 1.0 and adding preliminary support has a risk of being outdated quickly.

Hence my questions:

1. Is there, or could there be, some sort of pre-release versioning schema? Potentially even with milestones marking certain features as "stable" and others as "evolving"?
2. Is there some sort of ETA for a initial 1.0 release from which further extensions will be made, following a clear versioning strategy? I saw the v1 milestone here on GitHub, but there seem to be a lot ongoing outside the issues listed there.

I fully understand that a certain completeness on the general format/structure and the available content has to be reached for a stable v1.0 to avoid breaking changes. But targeting a specific "1.0-2025-08" draft revision than a constantly evolving "1.0 draft" seems more realistic. 😁

I wonder if the W3C practices have some recommendations there which could be followed. At least in the SMuFL repo I saw some date-versioned drafts.

[adrianholovaty]

Hi @Danielku15 — thanks for the message. Nice to see you're interested in integrating MNX into alphaTab!

Yes, I completely understand how the current state of MNX can feel like a moving target. We're a bit hesitant to add version numbers at this point (even date-based ones), since it seems premature.

With that said, I'm reasonably confident the current contents of the MNX spec are stable. The vast majority of our remaining effort is adding functionality as opposed to changing what's already in there.

Long story short, I'd encourage you to start giving it a shot, if you're willing to take the (in my opinion small) risk that you might need to rewrite some code if we make backwards-incompatible changes. Sorry if this is too wishy-washy to be helpful, but it's my honest assessment!

(BTW, we haven't yet specified how tab data should be encoded, and I'd love for you to be involved in that discussion.)

[Danielku15]

With that said, I'm reasonably confident the current contents of the MNX spec are stable. The vast majority of our remaining effort is adding functionality as opposed to changing what's already in there.

Thanks for giving this further insight. Good to know that things might be mostly extensions. I anyhow will need to check first the compatibility aspects between my data model and MNX as there might be missing features on either side 😁

Long story short, I'd encourage you to start giving it a shot, if you're willing to take the (in my opinion small) risk that you might need to rewrite some code if we make backwards-incompatible changes. Sorry if this is too wishy-washy to be helpful, but it's my honest assessment!

Generally I'm open for changing the format implementation regularly to meet again the spec. It might just need some more effort to define for myself a "revision" which I implemented so I can "diff" for any changes to adapt. I am not too worried about users flooding my project that things might be incorrect.

I thought of adding an importer(reader) and exporter(writer) for the format to easily bootstrap a regression test-suite.

(BTW, we haven't yet specified how tab data should be encoded, and I'd love for you to be involved in that discussion.)

Feel free to pull me into the loop there 😉 For alphaTab I anyhow plan to rework my data model in near future. I thought to take MusicXML and MNX as a main reference bringing-in aspects from other formats like Guitar Pro and Capella to cover all needs.

[paul-bayleaf]

I also would like to be in the loop for MNX's tablature specification. Although in my case my interest is in lute tablature - the ancestor of modern guitar tablature. I implemented French and German lute tablature for Verovio and I was involved with the discussions that led to the improvements to the tablature specification in MEI 5.1, particularly in catering for German lute tablature.

Lute tablature is not just of historical or academic interest, it is still very much in use - by lutenists.

[rpatters1]

I think it would be helpful to agree on a roadmap to 1.0. In the first meeting of this year (according to the published minutes) the committee agreed that it should commit to at least a subset of objects that will definitely be in 1.0. I have not seen such a spec.

In my experience with large software projects, they often fail if they do not have a "must-succeed" or "must-ship" imperative. It think a roadmap could provide more impetus towards a "ship" mentality. At minimum the roadmap would list every high-level feature that must be in 1.0, those that will be pushed to 1.x, and those that will be pushed to 2.0, and those that will be unspecified "future date". This can be an evolving roadmap, but it helps everyone understand what we are working towards and how we are going to get there.