-
Notifications
You must be signed in to change notification settings - Fork 23
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
Manual Stable Release #1862
Manual Stable Release #1862
Conversation
9588145
to
6b277ed
Compare
@@ -117,28 +117,33 @@ After doing that: | |||
|
|||
## Publishing a New Release |
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.
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.
LGTM
Agree with @odisseus that the -nightly suffix check can be simplified
Some more feedback inline
@@ -1,10 +1,4 @@ | |||
#!/usr/bin/env bash | |||
# This script implements the time-based version scheme from RFC 795 |
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.
Why delete this, particularly since client releases are moving to be more aligned with Sourcegraph releases, not less?
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 script does not work like the comment says. Also, we wanted "prettier" version numbers for GA.
Our current setup produces a lot of stable releases that often are not unhidden eventually. That makes the QA and awaiting JB approval process parallel. Based on the recent experience only 1/8 releases goes public. That is a waste of JB approval team's time and CI time. Let's change the setup. The nightly version handling does not change but the default release script does not longer publish the stable version. Instead the separate workflow can be triggered on the specific tag that publishes the stable version. ## Test plan 1. push a tag for a nightly release 2. trigger the stable release manually to be tested once merged
Our current setup produces a lot of stable releases that often are not unhidden eventually. That makes the QA and awaiting JB approval process parallel. Based on the recent experience only 1/8 releases goes public. That is a waste of JB approval team's time and CI time.
Let's change the setup. The nightly version handling does not change but the default release script does not longer publish the stable version. Instead the separate workflow can be triggered on the specific tag that publishes the stable version.
Test plan
to be tested once merged