![](https://secure.gravatar.com/avatar/b47d036b8f12e712f4960ba78404c3b2.jpg?s=120&d=mm&r=g)
W dniu 6 kwietnia 2010 18:31 użytkownik bulia byak <buliabyak@...400...> napisał:
2010/4/6 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak <buliabyak@...400...> napisał:
This sounds inevitable, but rather hairy. Why have both inkscape:version and inkscape:document-version? Can you get what you need with inkscape:version only?
- Document version changes must be atomic, because the upgrade is
conducted only one time for each type of defect. This means inkscape:document-version (or inkscape:document-format) can change several times between two releases.
But why can't we just fix ALL the defects we find between 0.47 and 0.48 and have just two states of upgrade for <=0.47 and for >=0.48?
The upgrade procedure must run exactly once for any document. This means that if we introduce a change in the interpretation of XML between revision FOO and FOO+1, then FOO+1 must perform the upgrade on documents saved in FOO and earlier, but it must also be smart enough not to upgrade documents saved with FOO+1. That's true regardless of how many defects are fixed in each version or how many document formats there are. This means the version number must be accurate down to a single revision, which is a bad idea for reasons I've already mentioned. If we have only the bare version number (e.g. 0.47 or 0.48), then anything saved in FOO+1 or later cannot be opened until we make a stable release.
It would be possible to have the document format version number equal to the Bazaar revision in which it was first introduced. However, this would complicate working on the backwards compatibility fixes in branches. I think a simple number increasing from 1 would be the best way to go.
This is hairy, possibly tedious to implement, etc., but at the same it's the long-term solution.
Regards, Krzysztof