Version string and upgrades

[Sean Colsen]

This is a topic for discussion that we could try to work out async or bump to our next meeting.

In researching and thinking through our version string and upgrade process, I’ve developed these questions for the team:

• If we end up later releasing a 0.2.0-testing.2 version, do we want to allow users to upgrade from 0.2.0-testing.1 to 0.2.0-testing.2?
• Do we want to give ourselves the opportunity to release a version named 0.2.0-rc?
• Do we want to allow users to upgrade from pre-release versions to 0.2.0?
• Do we want to make our version string officially conform to semver?

Depending on how we choose to answer these questions, we might need some code changes before our upcoming testing release.

Currently our code that compares two versions only looks at the major, minor, and patch values. It ignores stuff like -testing.1. That means that 0.2.0-testing.1 will be considered the same version as 0.2.0-testing.2 and as 0.2.0. So users who install 0.2.0-testing.1 will not have functioning in-app upgrades until we release 0.2.1 or later. If we want to fix that we need to make some code changes now. And in doing so, we need to consider what logic to use when comparing versions. The version string 0.2.0-testing.1 looks an awful lot like semver. It could be considered semver. But if we decide that a release named 0.2.0-rc should be ordered after 0.2.0-testing.1 then we can’t use semver because rc is sorted before testing.

I’d be inclined to:

• Commit to officially following semver, since our versioning scheme thus far has been in conformance with it.
• Keep our upcoming version named 0.2.0-testing.1.
• Agree that, given the above two points, we would not be able to subsequently release any versions with names like: 0.2.0-rc, 0.2.0-rc.1, 0.2.0-beta, 0.2.0-alpha (because they wouldn’t be sorted after the -testing versions).
• Release versions 0.2.0-testing.2 and 0.2.0-testing.3 and so on (as needed) until finally releasing 0.2.0.
• Before releasing 0.2.0-testing.1, swap out our front end version comparison code with a third party JS library that can parse and compare semver strings in conformance with the spec.
• Support in-app upgrade prompts from Mathesar 0.2.0-testing.1 for all future testing releases and normal releases.

If the above proposal sounds okay to people, then I don’t think we need to discuss any further. But if anyone has concerns, we could discuss here or at the next meeting.

​

[Kriti Godey]

I'm fine with the plan you've outlined, Sean. We do want to (have the option to) support upgrades between testing versions, and I don't think we need additional strings beyond "testing". I assume we could use the "rc" string for future versions (not 0.2.0) in lieu of "testing" if we wanted to.

Could you create an issue to implement the front end version comparison code changes?