You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A non-committer wouldn't be able to actually test the changes, as long as the PR looks plausible I would merge it and take care of making any needed final adjustments at release time.
RELEASING.md has the current release steps. I went through them manually just now to release 1.1.1 and to make sure I understood everything. Observations:
We need to be careful that the right matrix entries get published. Would just +publishSigned work as-is, or do we need to make some adjustments? At present the release steps have us doing publishSigned (without the +) to publish the 2.12 stuff including the sbt plugin, then you separately ++2.13 and ++3.2 and run coreJVM/publishSigned and coreNative/publishSigned. We need to be sure that all is handled automatically with sbt-ci-release.
We need to figure out what to do with testStaging. Currently the release process involves publishing to a staging repo on Sonatype, then using the staged artifacts for a final round of testing before release. We either need to automate that, or allow for it as a manual step. Perhaps the easiest thing would be for sbt-ci-release to only stage the release, and then the test-and-release steps would be manual? Or, perhaps testStaging could be automated to use publishLocaled stuff?
I think we can lose it. It was initially a manual step added in 7cfb5e7, but if we can get to a place where it isn't needed then so much the better. Thanks Seth, releases are such a pain for me.
Volunteer for this?
RELEASING.md
is the current status quo and will need updating along with the build changes.The text was updated successfully, but these errors were encountered: