New version and structure of repository

[julianu]

In #44 I created a pull request for the version 0.1.0 for our CV.
Besides the starting from scratch of all terms, the CV imports the 0.0.8-legacy for backward compatibility. We should highlight somewhere (at least on the 1.0.0 release), that all terms below QC:4...... are deprecated. and should no longer be used. This could also easily be reflected in the legacy-cv later on.

As we also should have a stable link-position for the current versions of the CV, the file "qcML-development/cv/qc-cv.obo" was created, which should in the future always represent the newest active version. Besides it also resides the legacy version.

I think this also reflects your ideas @mwalzer, right?

Please comment or merge the PR.

[mwalzer]

👍
I just created a label for v1.0
and a management board

[poshul]

Playing necromancer here for a bit, finding what happened to the old CV's was challenging with current documentation. I'd suggest including a note somewhere in either the readme or the spec-doc as bread-crumbs for anyone getting up to speed.

[bittremieux]

Which version did you need specifically, and what is different about it?

Normally CV updates will only consist of additions, so the latest version should have all the terms of older versions as well. Why would you need an older version of the CV?

[poshul]

OpenMS has some code to handle QCml files that use the legacy (0.0.8) QC-CVs. Currently loading these fails because the CV terms are missing from the modern OBO file. (For now we are handling this by also loading the OBO from the 0.0.8 branch)

…

On Thu, Sep 9, 2021 at 4:41 PM Wout Bittremieux ***@***.***> wrote: Which version did you need specifically, and what is different about it? Normally CV updates will only consist of additions, so the latest version should have all the terms of older versions as well. Why would you need an older version of the CV? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABD3C2V22O6VJOK5ROIFQLUBELYXANCNFSM4FXTPFJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bittremieux]

I think loading the OBO from the old branch is going to be the best solution.

Moving from qcML to mzQC was a non-backwards compatible change, and merging the QC CV with the MS now, as required before finalization of mzQC v1.0 (#141), will definitely not be fully backwards compatible either.
This is not a major issue imo, because there are very few legacy systems that support qcML. Probably OpenMS is the only such system.

Are there blocking issues that require maintaining qcML support in OpenMS, rather than switching to mzQC? mzQC is easier to write and read and more powerful to store data, so why stick with qcML as only tool that supports it?

[mwalzer]

Axel is working on that in OpenMS already, no? But if need be, we could create a dedicated legacy qcML branch, with the old stuffs, I suppose.

[poshul]

If we are the only software that's going to have to worry about backwards compatibility of reading the old files then I can just make a note in our code that uses the old CVs.