Sailfish Silica versioning

Sailfish Silica does get updated regularly with new OS releases and as an enthusiastic user and developer, I am usually on the latest version. However, not all users are on the latest version and as a developer I would like to continue supporting these users as well.

It would be nice if Silica made use of the versioning system Qt/QML offers. This way as an developer I would be able to target older Silica versions with the QML engine and QtCreator giving a warning when using newly introduced components and properties for existing components. Right now, I would need depend on users on older versions submitting bug reports if something breaks in older Silica versions.

Sadly, as a student and the development of Sailfish applications being nothing more than a hobby, I do not have the resources to own multiple devices for testing. My Sailfish phone is my only and main device (besides a feature phone if the call part somehow would break).

As an example:

import QtQuick 5.6
import Sailfish.Silica 3.4 // Because of Sailfish 3.4

ApplicationWindow {
    background.color = "purple"; // Error: background.color is not a property of ApplicationWindow
}

If import Sailfish.Silica 4.0 was used, it wouldn’t give an error, since the property actually has been introduced with Sailfish 4.0.

5 Likes

This would be great also from a maintenance point of view. Knowing which version a component was developed for helps with keeping track of outdated code, refactoring, and keeping things current.

I suggest not to base the version number on the Sailfish release number, though. It would be great if something like semantic versioning (semver.org) could be used, i.e. the major version should only change with major changes.

If versioning is implemented, it would be very important to have versioned documentation archives too. This would also help developers with keeping track of recent changes, which is important for writing good code.

3 Likes