RFC: A new versioning strategy for Discourse

The point of SemVer is that the version number should communicate some useful information. The only information communicated by your proposed scheme is the earth’s orbit around the sun. That information is not very useful to the consumer of the software.

If for some reason I did want to know the date of the release, I would look at the release and get the full date.

Not really. The point is to communicate the nature of the release to the user.

If the release is a patch version bump, this is communicating that the changeset doesn’t contain anything that is expected to affect the workflow of the users of the software.

If the release is a minor version bump, this is communicating that the changeset includes the addition of new user facing components, but nothing that will break existing workflows of the users of the software.

If the release is a major version bump, this is communicating that the changeset includes changes that may break existing workflows of the users of the software.

The determination of which of the version components should be bumped is more clear cut in a software product that has a single user interface, but the principles remain the same even for a software product like Discourse where there are a variety of levels of interfaces and types of consumers (e.g., plugin developers, API consumers, forum staff, end users).

Even if the choice of which component to bump is a bit more subjective in this software project, it still results in the version number having meaning instead of just being some arbitrary number, as is the case with your proposal.

2 Likes