-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new release process / CI actions / checks #344
Comments
It needs a formal definition, i.e. what tests need to pass. E.g. does it imply testing on a full live data in Finney?
What if the main branch goes forward from the commit that we want to release? How do we update version in the release? How do we apply hot fixes if we don't want further commits (already present in main branch) to be included in this release? Does it mean merging of PRs is blocked until the release is finished? What happens to the on-going feature branches if they need to merge upstream commits that are not included in this release during the release process? |
So right now this is defined based on the label rules which means it has to have the
I can also add other required labels if necessary
This will regularly happen, the tip of
I'll be doing this manually with each release. One thing that might help this process is if we add labels or something to indicate on PRs what level of semver change they necessitate, so I'll definitely add something about this to the PR templates and/or docs
When you cut a release it can be based on any tag you like, so that's how we would do that. If there is a hotfix we merge it into main and cut a release. Everything already in main that hasn't been deployed to finney will already be, by definition, ready to go on finney, so that will be fine. With the old approach this is more of a problem because we have things in the |
related Q: how do we feel about semver with respect to this stuff -- what sorts of things constitute a patch, minor, and major version change when it comes to subtensor? |
Thanks for details, @sam0x17 ! I have just one concern that this pipeline may become a bottleneck if we have too many pending PRs waiting for approval. If features depend on each other, it will be tempting to cross-merge without waiting until the PR is accepted in the main branch. Would be great if we have some rules about cross-merging to prevent mess. |
I agree this is a potential issue, but so is the churn created by everyone being rebased off of a My hope is that we can do more frequent releases and that that will be the answer to this concern. Right now stuff can't move forward until all the other stuff in its "cohort" is tested, this would let things move more independently of each other |
We want to move to a more formal release process characterized by the following points:
main
on-devnet
,devnet-pass
,on-testnet
, andtestnet-pass
, respectively, and having both thedevnet-pass
andtestnet-pass
labels will be required by the CI to merge into main.all work in #346
AC:
devnet
/testnet
stages (possibly using labels)main
The text was updated successfully, but these errors were encountered: