Would be quite important to support "releases" of some sort, the idea would be that we have a new rubhub/releases branch that works similar to the issues, as in it contains a bunch of directories releases/v0.0.1 for example, this directory should contain a README.md with release notes and all artifacts. This name should also always be the same name as a tag which points to the commit actually used for that release, this way the backend can already bundle up a tar.gz/zip of the source code for the user.
One important invariant that the system should enforce is that releases are immutable, of course a user could force push and rewrite history, but outside of that RubHub should provide no means to edit an existing release, we should however allow for draft releases so that a maintainer can gradually add artifacts, rewrite the release notes and so on and only when they press the "Release" button will it become actually immutable, we should probably have 2 directories, drafts/ and releases/, on a proper release that particular tag dir will just get moved over, while a draft we also should not require the tag to actually exist, that way a maintainer could just keep a draft release around during development and then just append the changelog for example, not sure whether it'll be used but we should enable a workflow like this.
Would be quite important to support "releases" of some sort, the idea would be that we have a new
rubhub/releasesbranch that works similar to the issues, as in it contains a bunch of directoriesreleases/v0.0.1for example, this directory should contain aREADME.mdwith release notes and all artifacts. This name should also always be the same name as a tag which points to the commit actually used for that release, this way the backend can already bundle up a tar.gz/zip of the source code for the user.One important invariant that the system should enforce is that releases are immutable, of course a user could force push and rewrite history, but outside of that RubHub should provide no means to edit an existing release, we should however allow for draft releases so that a maintainer can gradually add artifacts, rewrite the release notes and so on and only when they press the "Release" button will it become actually immutable, we should probably have 2 directories,
drafts/andreleases/, on a proper release that particular tag dir will just get moved over, while a draft we also should not require the tag to actually exist, that way a maintainer could just keep a draft release around during development and then just append the changelog for example, not sure whether it'll be used but we should enable a workflow like this.