This repository has been archived by the owner on Sep 20, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes the logic of CI action that determines the next OpenPype version with each nightly and production release.
Untill now, any PR that was labeled with
type: Feature
triggered upping of the minor version, however because of that it became quite hard to tell when we need to re-deploy re-built executables, and when it's enough to use automated system with zips.With this change we're making this a lot more transparent.
If a pull request requires a new build of the binaries, due to changes in the igniter, pyproject.toml or similar major changes, it is the responsibility of the Author and the Reviewer to make sure the PR is labeled as
Bump Minor
.CI will pick this up and make sure that minor version is updated next time this PR makes it to a release. The main upside being that from now on, we should be able to easily tell if a new build needs to be deployed to studio or not, by watching out for minor version bumps.
3.9.0 -> 3.9.3 -> 3.9.x
- shouldn't require new build3.9.3 -> 3.10.1
- will require a new build to be deployed to artist.