W dniu 7 kwietnia 2010 17:11 użytkownik bulia byak <buliabyak@...400...> napisał:
This makes sense, but I still cannot understand why you can't have instead
case 0.47: ... case 0.48: ...
etc. Is this that you're trying to care for the users of daily builds between 0.47 and 0.48?
Consider this: 1. I open a 0.47 document with 0.47+devel that has the coords fix 2. I save this document 3. I open it again with the same 0.47+devel
In step 3, how do I know that I've fixed the guides already? If I fix them again, they will be mirrored vertically and we fail. Do I write inkscape:version="0.48" to the SVG after fixing it, even though the actual version is 0.47+devel r9876? I don't like this, because: 1. The SVG now lies about what created it. 2. We can change the document format only once per release. 3. We can't have a revision (let's call it 0.47+foo) that fixes only some defects (e.g. fixes guides but not 3D boxes), and later add more fixes. Otherwise if somebody opens a file in 0.47+foo and saves it, the file will be permanently broken. Later revisions that do fix e.g. 3D boxes will recognize it as already fixed and do nothing to remediate remaining problems. 4. If two people decide to do something that requires XML compatibility fixes in a single release, it will be hard to coordinate between them.
If we don't change inkscape:version in the document and don't introduce a new field, then it would be impossible to use the trunk for any work between the time an XML fix is introduced, and the time the stable version is released. Merging XML fixes just before a release is an extremely bad idea, since there would be much less time to test them.
So far there are three possibilities for the document version number: 1. Inkscape major version. 2. Bazaar revision. This would mean extra code when Inkscape is built from a tarball with no VCS, and in general unacceptably strong ties to the VCS and the build system. Also problematic when working on XML fixes in local branches, which have different revision numbering than the trunk. 3. Some number not tied to Inkscape version, stored as a constant in the definition of the upgrade procedure (what I proposed).
If you don't like the fact that document version numbers would appear unrelated to the Inkscape version, I have to point out that this number doesn't have to be increasing sequentially from 0. The switch will work correctly no matter what the sequence looks like, as long as it doesn't have duplicate elements. It doesn't even have to be monotonic. We can use document format numbers like 4701, 4702, 4703, 4801, 4802, 4901, etc. and store them in XML as "0.47-01", "0.47-02" or in any other easily parsable form.
Minor nitpick: you can't switch on floating point numbers in C++.
W dniu 7 kwietnia 2010 17:29 użytkownik Jon Cruz <jon@...18...> napisał:
Oh, and yes. Among the cases I'm concerned about are those where something is removed from our extras earlier in the dev cycle and then added back before release, or where something is added or changed in an interesting way and then changed back before release. Both are among those situations where a simple case statement implementation will cause data loss.
Those cases would cause data loss only if the rules for modifying the switch are not followed. In particular, you are not allowed to remove code for any of the existing document versions or redefine what operations are performed between document versions. The switch is append-only.
If you made some XML fix that e.g. changed the way some coordinates are expressed but before a release you suddenly think it doesn't make any sense, you have to bump the document format and add code that reverts the fix, rather than removing the code that executes it. As long as the switch is append-only, and none of the upgrade operations cause data loss, it will work correctly.
You can also add a goto to skip the fix-revert sequence if the document version is earlier than the version which introduced the unwanted fix, or if the fix actually breaks something and you only do best-effort recovery when undoing it. However, I would be very careful when adding such shortcuts.
Regards, Krzysztof