-
Notifications
You must be signed in to change notification settings - Fork 60
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
Quality on Demand: Fix RETRIEVE_SESSIONS_EXAMPLE #344
Quality on Demand: Fix RETRIEVE_SESSIONS_EXAMPLE #344
Conversation
Main version set to wip again
@@ -60,15 +60,15 @@ info: | |||
license: | |||
name: Apache 2.0 | |||
url: https://www.apache.org/licenses/LICENSE-2.0.html | |||
version: 0.1.0-rc.1 | |||
version: wip |
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.
If we want to fix this for the meta-release, shouldn't this be version: 0.1.0-rc.2
, rather than going back to wip
at this stage?
Same comment for server URL, and for other YAMLs.
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.
@eric-murray going back to wip is correct ... it is indicating that these commits are not part of a release, but the work in progress between the releases. There could be further bug fixes to the same file before we create the next (pre-)release. The version will be set again in a release PR ... could be either 0.1.0-rc.2 (if it would make still make sense) or already 0.1.0.
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.
OK. In that case, I think I'd prefer a specific PR to reset version
and url
immediately after a release, independent of any other changes. Otherwise all subsequent PRs need to include these changes until one of them is merged.
For this PR, we need to decide if this change will be part of the next release or not before merging.
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 problem would be if we wanted to work in parallel: fixes for r1.2 (RC.2) and new content for a future meta-release (r2.1). Without branches that is not possible.
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.
For this fix of examples I guess the decision is clear that we want to have them in r1.2. Therefore I'm in favour to merge it asap (to resolve also the version reset).
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
What type of PR is this?
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #343
Special notes for reviewers:
To be considered for r1.2 (RC2)
Changelog input