How often should we do "release" tags?

[dreemkiller]

To ensure a manner of stability, we need the concept of a "release" where we guarantee that things will work (build, run) for a set amount of time after the release.
There's two points of discussion on this:

1. How often should we "release"?
2. How long should we commit to making sure the build works for them.

Issues that need to be maintained on 2: github repos needed for that build need to be kept, and kept public, for the duration of the support window.
I don't think we need to commit to backporting bug fixes to each of these releases at this point, however (that's probably a bridge too far for a research project).

[dominic-mulligan-arm]

For reference, I think we promised the CCC that we would create a release every two months. I think the answer to (2) depends on the actual mechanics of the release, though:

• If we just tag a point, using Git tags, on the main branch which is known to be "good" (i.e. it corresponds to the merge of a pull request, and so is guaranteed to be buildable) then there isn't really much to maintain. We only guarantee that the individual tags build, and don't provide any further guarantees other than that.
• Alternatively, if we e.g. fork off a release from the main branch into a dedicated release branch, e.g. 0.3.0, or whatever, then we do need to decide how long these releases are maintained, moreover we need to decide what gets back-ported from main onto these new release branches. Security and bug fixes, only? Larger features?

[dreemkiller]

I support the "tag" mechanism, because it's lightweight. Forking is useful if we intended to port bug fixes to previous releases, which I don't think we should commit it.

However, it's not just as simple as that, as I learned this week. We tag the veracruz repo with the version, knowing it builds. However, it also means that anonymous users need to be able to access all of it's dependencies (some of which we control). We can't take dependencies and make them private, or delete the repo, for example. I think the easiest way to make sure of this is to do periodic builds of each of the supported tags.

[dominic-mulligan-arm]

Ah OK, yeah, thinking more you are right (and you actually pointed this out in your original message, which I missed): we need to commit to dependency stability for any such release. Given we have committed to releases every two months, does it make sense to only support the single previous release until a new release is created?

From a technical POV, I think we can expand our current CI to build all of our currently supported tags every day, along with main. Though, I think it will be easier for us to do that with AWS CodeBuild by actually creating a new branch for each release, which never gets updated and just acts as a marker (I think you can only schedule a build for a particular branch, not a tag). @ShaleXIONG what do you think?

[ShaleXIONG]

I prefer 'tag' too, because I do not think we are an industry-level software which needs to maintain several versions. Most big open sources use branches for backward compatibility since they have a lot of users. I think to extend to CI to capture either tags or branches are the same setting. AWS CodeBuild allows specifying an (optional) source. Yet I think it only allows specifying one source at a time. Therefore, if we use a release tag or a branch, we need to constantly bump this.

[dominic-mulligan-arm]

How many previous "releases" are we therefore going to support? I think supporting only the previous release is appropriate in our case. What does everybody else think?

[dreemkiller]

That feels fair. More than that, and it begs the question of why they haven't updated.

[ShaleXIONG]

I will say only one release. We can keep all the old tags/branches but do not provide further supports.

One case we could end up supporting more releases is that of updating SDK, e.g. sgx-sdk or optee. In this case, if Veracruz is used in any production env, it will be way more painful to update the SDK used in the production env. This takes into account that users might try to run Veracruz outside of our docker image.