The Big Picture
After the release of version 0.11 I took some time for exploratory thinking. Upon my return from vacation I went to work on the “distribution” part of “app packaging and distribution”.
I collected links to tools and libraries that are used for translating apps with the goal of some day doing the work of making Dropserver localizable.
Tailscale has the potential to give users access to a self-hosted Dropserver instance without exposing that instance to the broader internet. I spent a bit of time trying to learn more about what it can do. I collected a few videos to watch during my vacation (I did not find the time to watch them 😑).
Back to coding
I’m back at work now writing code (sluggishly). The next release will make it possible to publish apps and Dropserver users will be able to get automated upgrades to the latest app version (opt-in of course).
I’m working on integrating release notes aka “changelogs” in packaged apps.
I did a bit of research and found some interesting things about changelogs in major platforms.
I had punted on changelogs for v0.11 because I do not love the naïve approach I could take: simply include a markdown file with all release notes for shipped versions in reverse chronological order. I would like to be able to pick out the release notes for specific versions. A lot can be done to present things usefully for the user once you can pick individual version notes.
Another concern is the security implication of showing markdown content created by 3rd parties in the user’s admin panel. This can not be the source of a vulnerability. To show markdown (or HTML) safely I would have to filter the content through a library like bluemonday on the server side, and display it in an iframe to gain two layers of protection against potentially malicious content. This is more work than I’d like to do right now, so I’m sticking to plain text.
I decided to make plaintext file (not markdown) for changelogs, where the changelog for version x.y.z is preceded by a line consisting solely of “x.y.z”. With that, devs can easily write changelogs in a text file and the system can easily parse that file to extract the changes for a given version.
Having a structured changelog format allows me to do the following:
- warn if no changes entered for latest version (each version should include a changelog)
- present other metadata in listing of changes (release date, package size, API version, etc…)
- show the changes made between the currently installed version and the version about to be installed (useful if user did not upgrade for a few versions)
- if upgrade includes a major rev, highlight the changes for the major release (x.0.0) which are usually lengthy and describe meaningful changes
- if some changes have been translated into the user’s preferred language, show these instead of the developer’s original version.
August was mostly spent not working. This Fall I will be busy with a number of non-Dropserver things but I should still be able to make good progress.
I’ll be working on app distribution and automatic upgrades which will result in release of version 0.12.