Tag releases and add a change-log

[justinmayer]

May I humbly suggest that the project adopt the following?

• a change-log
• SemVer-based version numbers
• Git tags
• GitHub releases

These enhancements would allow for version pinning as well as greater visibility into what has changed between one version and another.

I would be happy to lend a hand if that assistance would be welcome.

What do you think, @lukevella?

[lukevella]

Hey @justinmayer, yes absolutely that would be welcome. I'm not sure if semver would make sense since this is not an API and there can be no breaking changes between versions.

[justinmayer]

Fair point. Even if there are no breaking changes between versions, I still think semantic versioning has value to communicate the magnitude of changes (i.e., big features, small features, bug-fix patches).

[lukevella]

Sure ok, that sounds reasonable.

[samsapti]

Hey @lukevella, when do you plan to introduce the suggested changes? When SemVer (or similar) is introduced, I'm ready to do a PR to make the Docker image workflow support it 🙂

[lukevella]

Hey all, sorry for the delay. Finally came round to working on this. I'll be making releases with a detailed change log from now on. Sorry it's taken a while to get to this but better late than never 😬

[lukevella]

You might notice that I tagged the first release as v2.0.0. The reason for this is because technically v1 of Rallly was released in 2015. However I'm not sure about this decision now since most people would not know about this version and it may be confusing to see the first tagged release being v2.0.0, perhaps it would make more sense to have the first tag be v1.0.0 or even v0.1.0 and wait till the project is a bit more mature to give release v1.0.0.

Would be glad to hear other people's thoughts on this.

[samsapti]

@lukevella personally I would've preferred to start with version 1, but it's probably too late to change now since many people are already running at version 2.x.x (including us at data.coop), it's no big deal though. I think version >=1.x.x is fine, the project is mature enough for that :)

Just one question: Will the project follow SemVer, i.e. minor and patch upgrades don't introduce breaking changes (including for self-hosting / Docker Compose configurations)? Just so I know what type of version pinning would be more appropriate for a production setup (minor or major). Thanks!

[lukevella]

Yes correct. The semver versioning is primarily for self-hosters to ensure they do not accidentally introduce breaking changes. To summarize:

• patch: bug fixes, small refinements
• minor: backwards compatible update
• major: breaking changes

When there is a new major release I will include instructions for upgrading to the new version.

[samsapti]

That sounds great! I really think Rallly is a great project, so it's nice that it's so easy to self-host. Thanks for the introduction of SemVer :)