Right now, we run publishing from the release branch. While it is a protected branch, and that helps a bit by forcing us to release through PRs, it is quite annoying to release, and it takes quite a while. Instead, we can just use tags from commits on main. Here's what I think the release process should be (based on a hypothetical 10.3.4 release):
We create a release-10.3.4 branch from main when we're ready to start testing.
On that branch, create a .zip folder and a .bat file that can be ran to download the chrome extension.
Send the .bat file to the testers, and have them do their thing.
Once we're ready to release, create a commit titled 10.3.4, and put all the version increments into it. This commit will be tagged with v10.3.4.
The release suite will run on the creation of the tag, and eventually publish the extension to the chrome web store.
Are there alternatives you've considered?
We don't really need to do this, but it frees cluttering merge commits and things like that.
@GeoFS-Extensions/authors your thoughts? I'll make this a tracking issue if we end up wanting to do this.
Is there an existing issue for this?
Description
Right now, we run publishing from the
releasebranch. While it is a protected branch, and that helps a bit by forcing us to release through PRs, it is quite annoying to release, and it takes quite a while. Instead, we can just use tags from commits on main. Here's what I think the release process should be (based on a hypothetical 10.3.4 release):release-10.3.4branch from main when we're ready to start testing.10.3.4, and put all the version increments into it. This commit will be tagged withv10.3.4.Are there alternatives you've considered?
We don't really need to do this, but it frees cluttering merge commits and things like that.
@GeoFS-Extensions/authors your thoughts? I'll make this a tracking issue if we end up wanting to do this.