ODK tools have all historically used something that looks like semantic versioning. I think the biggest advantage is that version strings that look like vX.X.X are familiar. Here are some issues:
- It's unclear what "breaking changes" are in user-facing tools (as opposed to APIs). We now have 31 minor versions of Collect. Downgrades are typically possible but in practice are not practical and may result in loss of local data. Should some of those have been major version increases?
- Making a major version change feels like a really big deal and it's unclear what should trigger it. We have many small changes that will break some users in the next release (removing support for unscoped storage, removing support for the Aggregate 0.9.x API, removing support for file-based settings import [used 9 times in the last year]). Should those trigger a major version change even though we expect the number of affected users will be very small?
- Should multiple project support trigger a major version change because it's a big addition? Even though we're designing it so that most users should be entirely unaffected?
- We almost certainly have additional big changes coming up with explicit support for entity-based workflows. We'll sandbox those changes so that they only show up if a project configuration requires it. It will likely be a set of features that we expand on over time. Should the start of these additions trigger a major version change? Reaching some threshold of functionality?
- We display a version number in Collect so that team leaders can quickly verify that all their data collectors are on the same version. This works well but it doesn't give teams any sense of how recent their version is. We see various problems from users running really old versions. If they saw
v1.5.0, they might be more inclined to upgrade.
- We release Collect when we have a set of changes ready so the pace of updates is irregular. When a user says they're running
v1.21.1, that gives us no context. However, something like
2019.3.1(first patch of the third release of 2019) would tell us a little bit more.
Items 1-4 suggest that we have decisions to make about Collect versioning coming up no matter what. Given that I don't have a clear sense of what a major version change means for Collect and that I'd love to avoid handwringing around when we do it, I'd like to propose we change the versioning scheme to
That would also give us some nice little benefits like 5 and 6 and I can't currently think of downsides (that's where you all come in ). @Grzesiek2010 pointed out that the
release number could be interpreted as a month which is possibly misleading but I think even that misinterpretation carries more information than our current versioning scheme.
JetBrains, the company behind the IntelliJ development tools (which powers Android Studio), moved to this style of versioning in 2016 (with somewhat more complexity because they have many subproducts). As a user, I've found it helpful and their reasoning in the linked article resonates with me.
I don't have strong feelings about other ODK tools moving to this convention. I don't think it needs to be a coordinated effort.