Open NickLarsenNZ opened 1 month ago
Nice, I like the options. I'm also torn. I like both the .versions
bit but also like products (a faux key) being hoisted up.
I think I lean toward option 1. It seems more "correct".
+1 for switching from .py
to .toml
-1 for managing multiple releases in main
. We already have release-*
branches that may contain much more than just versions. These would clash and make maintenance harder.
-1 for managing multiple releases in main. We already have release-* branches that may contain much more than just versions. These would clash and make maintenance harder.
To be honest, I'm not a huge fan of release branches as they can often be hard to work with. But I can understand, why we want to keep the current workflow and how tracking Stackable releases in multiple places will cause pain points later down the road.
An alternative syntax could look like this:
[versions."2.8.3"]
dependencies = { python = "3.9", vector = "0.39.0" }
# Identical to above, just an alternate way of writing
[versions."3.0.0".dependencies]
python = "3.11"
vector = "0.39.0"
Switching off release branches is completely out of scope for this issue, so let's discuss that at a later point.
We currently track supported product versions and dependencies in a
versions.py
file (which is imported by theconf.py
in the root of the repo, which is in turn imported bybake
.Ideally, configurations should be static which would also simplify how this is imported.
Ultimately,
bake
could then be upgraded to not import a conf.py but rather load in TOML configurations.This could also then become the source of truth for tracking versions for upcoming releases. It could also help with making versions concrete leading up to a release (eg: a PR opened for the release, and kept open until version freeze a few weeks before a release).
Configuration Example
Option 1
The top-level
releases
table keeps track of the Stackable releases. Each product can then declare which versions are available for that Stackable version. The example below, lists two Stackable releases:24.3
and24.7
. The24.7
release is marked as active.bake
would need to validate that only one Stackable release can be marked as active. The example then declares available product versions per release, in this case2.6.3
and2.8.1
for24.3
. The table then lists dependencies and their version.JSON structure
```json { "releases": { "24.3": { "active": false, "2.6.3": { "python": "3.9", "vector": "0.39.0" }, "2.8.1": { "python": "3.10", "vector": "0.39.0" } }, "24.7": { "active": true } } } ```Option 2
This option changes the declaration of product versions and it's dependencies slightly compared to above. It is closer to the current
versions.py
format.JSON structure
```json { "releases": { "24.3": { "active": false, "versions": [ { "product": "2.6.3", "python": "3.9", "vector": "0.39.0" }, { "product": "2.8.1", "python": "3.10", "vector": "0.39.0" } ] }, "24.7": { "active": true } } } ```