Differences
This shows you the differences between two versions of the page.
|
|
|
dev:file_format_version [2009/12/06 05:21]
michael created |
dev:file_format_version [2009/12/06 05:28]
michael |
| In practice, this should be done any time we make changes that add new XML element types, or extend existing ones. What prompted the creation of these guidelines was that I added several new types of events to what is now file format version 1.5.0, and I wanted to investigate what would happen if I created a file that contained some of these events, and loaded it with the previous version of Rosegarden. Of course it silently stripped out all the new events with no protest, because I hadn't changed the minor version number (until just now). | In practice, this should be done any time we make changes that add new XML element types, or extend existing ones. What prompted the creation of these guidelines was that I added several new types of events to what is now file format version 1.5.0, and I wanted to investigate what would happen if I created a file that contained some of these events, and loaded it with the previous version of Rosegarden. Of course it silently stripped out all the new events with no protest, because I hadn't changed the minor version number (until just now). |
| |
| Looking back, I can think of a great many times when we should have changed the minor version number, but did not. It should be much higher than it is now, but there is no advantage to jumping it up to account for all the missing increments. **We need to pay more attention to this in the future!** It's not generally life or death stuff here, but it's pretty rude not to warn our users that we're about to strip out portions of the file they just loaded, because it was created by a version from the future, and we don't know what to do with those elements. | Looking back, I can think of a great many times when we should have changed the minor version number, but did not. It should be much higher than it is now, but there is no advantage to jumping it up to account for all the missing increments. **We need to pay more attention to this in the future!** It's not life or death stuff here, because we seem generally able to preserve elements from the future without stripping them out (to my pleasant surprise it turned out just now) but this just seems like good housekeeping. |
| |
| We should not hesitate to change this whenever we introduce any change to the XML file format. (Hopefully if you do this, you know what you're doing when you do it, and I don't have to spell all of this out for you.) We should increment the minor version number on the first XML change in a given release cycle, and leave it there until the release is away. There is usually no need to increment this multiple times in the same release cycle. | We should not hesitate to change this whenever we introduce any change to the XML file format. (Hopefully if you do this, you know what you're doing when you do it, and I don't have to spell all of this out for you.) We should increment the minor version number on the first XML change in a given release cycle, and leave it there until the release is away. There is usually no need to increment this multiple times in the same release cycle. |
