Release Candidates and Release Versioning

[eradman]

I have been thinking about the best way to get Redash into a private Jenkins pipeline so that my colleges and I can test it with the many tools we have built around it.

My I suggest that we tag a version with YY.MM every month and add a .NN for releases

Branch  Tag
------  -------
master  23.10    October snapshot
master  23.11    November snapshot
master  23.12    December snapshot
23.12   23.12.0  December release
23.12   23.12.1  December release + bug fixes
master  24.01    January snapshot
23.12   23.12.2  December release + more bug fixes

Using this scheme we can include Redash in a larger CI pipeline regularly. Aside from the tag, it appears that the version number is also recorded in two files:

package.json
redash/__init__.py

[guidopetri]

Overall - I think this is a great idea. I'm much more a proponent of "rolling" releases than Big Version Change releases.

How would a January bugfix release work for a December release in your setup? 24.01.1? (or would you just consider it a new release?)

[eradman]

Good questions! I think the answer would be derived from the method of cutting releases.
If we create a branch for each release then the bugfix tag would always follow the branch name. I'll edit my post to show this pattern.

[justinclift]

Seems like a workable concept. 😄

[guidopetri]

Thanks for the edit! I think this looks good too.

[justinclift]

@getredash/maintainers What does everyone think of this? 😄

[lucasfcnunes]

Calendar Versioning (calver) vs Semantic Versioning (semver) is a tough one. I understand that redash isn't a simple lib with simple "semversionable" traits so that calver can make sense.

How would it impact the helm chart and api lib?

[justinclift]

That calver.org page is useful. 😄

@grugnog Using Calendar Versioning should be pretty transparent for the helm chart yeah? It's pretty much just jumping up to major version 23 (instead of 11) in the short term, and using month-of-release instead of 0, 1, 2, 3 for the minor versions. Patch number is still the same.

[eradman]

Thanks everyone for the feedback!

I proposed a github action to update the version string and tag a release candidate each month:

#6416

[justinclift]

Merged! 😄

[eradman]

The periodic action to tag release candidates failed (https://github.com/getredash/redash/actions/runs/6366629264)

 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'https://github.com/getredash/redash'
Error: Process completed with exit code 1.

I'm not sure what permission needs to be changed. I think one way to solve this is to modify the default permissions granted to the GITHUB_TOKEN (Actions -> General -> Workflow permissions)

I manually added the tag for October

git tag 23.10.0-dev
git push origin 23.10.0-dev
git push redash 23.10.0-dev

[justinclift]

Hmmm, when did you manually add that tag?

When I did a git pull around 5 hours ago, it pulled down a new 23.10.0-dev tag (on the 3d32c55 commit).

[justinclift]

Looking at the error message protected branch hook declined... hmmm...

That sounds like the branch protection setting we have to stop direct pushes to master. Which kind of makes sense now I think about it.

Seems like it's getting in the way here though.

We might be able to figure something out with some kind of specially defined "Personal Access Token" we can store in a repo secret (not sure though):

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token

[eradman]

Reopening while we debug the github action