Tagged Releases

[Beethoven-n]

I'm working on a PR in a project where the devs are concerned about the possibility of a rogue developer attack.
Would it be possible to provide tagged releases alongside the continuous build to mitigate that issue if it were to come up?
StardustXR/telescope#8

[Schmarni-Dev]

it doesn't even have to be proper tagged release, even setting up CI to create a release for every commit or something would be good enough, basically anything that allows us to get something that should have a stable hash

[lalten]

Would love to see this. See also the discussion in #133

[probonopd]

Are there any volunteer Release Managers?

[orazioedoardo]

I could help with this, but should decide what to do with “continuous”.

setting up CI to create a release for every commit or something would be good enough, basically anything that allows us to get something that should have a stable hash

[probonopd]

I imagine that “continuous” should be kept as it is now, and occasionally, these releases should be tagged after a few weeks with no breaking bug reports. At the same time, a new build should be triggered so that a new “continuous” release gets created by the CI.

Users could then decide whether to use the “continuous” one (default) or a released version. But be aware that the released version receive no support/updates, only “continuous” does. (Unless we find someone willing to backport things into releases - not me.)

[orazioedoardo]

So you don’t feel like having automated tagged releases on commit like the user suggested above?

[probonopd]

Not really, because tagging something (to me) suggests it has been at least somewhat tested... plus, keeping all builds would fill up disk space really quickly.

[orazioedoardo]

Well those could be tagged as prereleases and regarding disk space… what disk space?

[probonopd]

The cloud... well, there is no cloud... there's only someone else's computer ;-)

[Beethoven-n]

much respect that you host the build for this on your computer and not github's lol

[orazioedoardo]

Here it is in my fork in case anyone wants, same workflow, albeit a bit simplified for practical use cases and immutable: https://github.com/orazioedoardo/type2-runtime/releases.

[probonopd]

So how many of these are you going to persist @orazioedoardo? How do you envision the cleanup to work?

[orazioedoardo]

I'll keep them forever, merge changes from this repo, and trigger the workflow from time to time.

[probonopd]

So basically you'll put the kind of load onto GitHub which I'd wanted to avoid. Then I could do it here directly...

@Beethoven-n in your use case, wouldn't it be easiest to mirror a known-good version locally?

[orazioedoardo]

So basically you'll put the kind of load onto GitHub which I'd wanted to avoid.

It's few megabytes and freely allowed, public repositories have very few limits, it's fair use by far. I'm also not creating it on every commit, avoiding builds with debug symbols, and not building in chroot which doesn't end up being released.