-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some thoughts on version management #67
Comments
These are good points to think about indeed.
I'm not sure if it's strictly forbidden actually, but a version number should definitely be mandatory. I'll ensure this for v2.0. In practice I fortunately don't see many old documents without version number, considering that all our libraries and tools always output it.
Yes, but in practice we have always done only the latter I think, since the libraries always output the latest version, for which they were designed, regardless of what they read (this is what libfolia does too right?). This indeed might introduce backward-compatibility issues if you really want/need to maintain an older FoLiA version for a document. On the other hand, it would make the libraries more complex if they need to output older versions, and if we do that we have to guarantee it validates according to the older version, which is not trivial, as you already remarked yourself. The forward-forcing behaviour we have now hasn't really been a concern yet, but with FoLiA 2 it might be more so. Still, I'm not sure if it's really worth the effort to implement serialisation of older versions, even though in an ideal world it would surely be the nice thing to do.
The current v2 libraries should remain backward compatible with all previous FoLiA versions. (unless someone specifically creates a v2 only library perhaps, but it's too early for that). But upon modification and serialisation, they will then output v2 (at least, foliapy does so).
Yes, agreed. removing/renaming is a major change, which is why I now only do it for the transition from 1 to 2. |
well, libfolia DOES preserve the version number, which is different from the Python version. |
Hmm right, that is indeed a very important point. I wonder if I keep the version at 1.4 then for those older documents, I'd have to check. |
I added some compatibility for serialisation of v1 to foliapy (a |
I think we should spend some time on thinking about version management.
With every version, we introduce or change tags, features or the semantics.
Of course this is fine, as we add a folia version number to the document so in principle we know what to do.
But there are caveats:
especially older document don't always have a version number.
This is forbidden since 1.5 (@proycon am i right?) but all our tools should be aware of this situation, and assign a version number, reflection the situation. (libfolia assigns 1.4.987 as 'magic' number)
a FoLiA processor/program may read a document with some version and then
This puts some constraints on OUTPUT. In general I think the version should be preserved, except for the case where newer features are introduced. Preserving the version is not that easy though.
e.g: Some tags are changing their names.
When reading a 1.5 document using the
<alignment>
tag, we then must output it as<relation>
in 2.0 but still as<alignment>
for 1.5.We could choose to output with the current/most recent version of FoLiA, but this is also dangerous, as it might need 'fixing' parts of the document to match new requirements like text consistency and cause trouble for other tools outside our world. who aren't version aware yet.
Providing a tool to update a FoLiA document to the most recent version is part of a solution, but still a lot of older document are out there which will not (or NEVER) updated. Like in SoNaR, Nederlab etc.
Maybe we should also create a policy of NOT removing/renaming tags, at least not between minor versions, as this makes backward compatibility a real PITA.
Conclusion: We really should come up with some strickt guidelines. Discussion welcome.
The text was updated successfully, but these errors were encountered: