-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Chore/release ci #62
Chore/release ci #62
Conversation
In order to publish a new plugin at UE Marketplace we need to support three latest engine versiona (currently those are 4.26.0, 4.27.0 and 5.0.0). Since Sentry plugin belongs to |
5c0401c
to
c0b99bc
Compare
It is possible, but where do we push those? To three separate repositories? Is this the only way? Maybe we can specify the minimum supported version instead? How do others plugins handle this? |
I was thinking about adding three separate archives for each engine version with a properly modified .uplugin file to the release and leaving the repo source code itself without any changes. The idea is pretty similar to other Sentry repos (i.e. for Sentry CLI https://github.com/getsentry/sentry-cli/releases/tag/2.5.0 executables for different platforms attached to the release). Also, links to such archives can be used for plugin update submission at UE Marketplace. Unfortunately providing only the minimum supported version is not an option and the approach suggest above seems to be a common practice. Alternatively repo can contain three subfolders (i.e. Sentry_4.26, Sentry_4.27 and Sentry_5.0) for engine-specific plugin version each, however that looks like an overkill since there will be difference only in one file. |
OK, thanks for clarifying. Having the output repo structured to include multiple distributions sounds bad but also like the right think to do 🤕 What do we actually upload to UE marketplace? The result of |
d3b39ae
to
d10eca3
Compare
UE Marketplace has its own dashboard for publishers where one has to provide links to downloadable archives with plugin source code for each engine version that is supported: That's what makes me think that having those at repo release page will be a convenient thing for submitting updates. Regarding the existing plugin packaging workflow - in our case this is more like a validation that there are no build errors (currently only for Linux). Epic Games does exactly the same thing after plugin update submission anyway and takes care of deploying a pre-build version to the marketplace |
371eab2
to
8d1d5d5
Compare
3daf2e6
to
c8f1294
Compare
c8f1294
to
bc34367
Compare
minVersion: 0.24.0 | ||
changelogPolicy: auto | ||
preReleaseCommand: pwsh scripts/bump-version.ps1 | ||
targets: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the "UPM" target following in another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current plan is to stick to single repo and publish the three packages (one for each EngineVersion) as zip files as GH release artifacts.
I see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no more UPM, see PR description - for now we're sticking to a single repo
2nd step of #27 - keeping separately from SDK build scripts updates so that this doesn't blow up too much and is (much) easier to review.
The current plan is to stick to single repo and publish the three packages (one for each EngineVersion) as zip files as GH release artifacts.