I use the glyphspackage file format to make version control changes cleaner and more understandable. However, I’m finding that fairly frequently, opening a file and saving it in a new version of Glyphs is causing more changes than expected.
For example, in this commit, the designer used 3236 but I used 3227; as well as my changes, there are a large number of changes to the imagePath field. Other commits have just been pure noise as Glyphs re-ordered the custom parameters between 3221 and 3227.
I know that improvements and optimisations are a good thing, but this kind of noise reduces the usefulness of glyphspackage as a version control format. Can we expect any guarantees about the file format remaining stable, particularly during minor version updates (or especially between development sub-version updates!)?
Isn’t this what we can expect when using development versions? The obvious answer is that you should not use development versions in production. Working in the development branch is a dance between the Glyphs developers and us users. We want features and Glyphs want beta tester feedback. Things break and are put together in new ways during this process.
Claus is, as always, absolutely right. Never, ever complain about anything (rather be passive-agressively bitter all the time).
Jokes aside, it’s important to at least point out things that could be improved, especially if they may seem unintentional. Reordered custom parameters is something I also get a lot when versioning glyphspackage files. Is there some way to enforce a stable order of parameters?
On a rathe very aside note, was it considered to split the fontinfo.plist further? A separate kerning file would be immensely useful, since I find myself working on kerning while somebody else is changing around metadata, which makes merges a bit scary sometimes.
I tried to optimize anchor decomposition that then caused a lot issues that I tried to fix in the last few version. That produces a lot noise in the file. But that should be fixed now (I removed the optimization in version 3241). So now it should behave the same as version before ~3235.
Sorry for that.
