Update/maintainers.md #800
Conversation
Signed-off-by: CEHENKLE <[email protected]>
Signed-off-by: CEHENKLE <[email protected]>
Signed-off-by: CEHENKLE <[email protected]>
|
✅ Gradle Wrapper Validation success eb43228 |
|
✅ DCO Check Passed eb43228 |
|
✅ Gradle Precommit success eb43228 |
…of the organization. :( Signed-off-by: CEHENKLE <[email protected]>
|
✅ Gradle Wrapper Validation success d9ffe2a |
|
✅ DCO Check Passed d9ffe2a |
|
✅ Gradle Precommit success d9ffe2a |
|
|
||
| From [Apache’s versioning doc](https://commons.apache.org/releases/versioning.html) : | ||
|
|
||
| A release number is comprised of 3 components: the major release number, the minor release number, and an optional point release number. Here is a sample release number: |
There was a problem hiding this comment.
I would like us to say that we will follow semver, and not all of this.
There was a problem hiding this comment.
I've added a link to https://semver.org/ in the first sentence. I think the context is useful.
|
|
||
| Why do it this way? | ||
| Because it lets main evolve quickly, while letting us be a little more circumspect about 1.x and 1.0. It'll also make it easier for us to release if everything is clearly tagged (not having clear tagging made this release kind of a potchke). | ||
|
|
There was a problem hiding this comment.
You need to talk about -rc1, and -beta1.
There was a problem hiding this comment.
I'm not expecting that to be a going concern in ~6 weeks. If you think it's useful for past context, I can add it.
MAINTAINERS.md
Outdated
|
|
||
| ### PR Lifecycle | ||
|
|
||
| Here's the life cycle of a PR: |
There was a problem hiding this comment.
I would refer to CONTRIBUTING.md somewhere in here and try to not duplicate what the contributor is doing.
There was a problem hiding this comment.
removed PR lifecycle, added link to Contributing.
MAINTAINERS.md
Outdated
| 1. The developer should create a Github issue explaining the problem, steps to reproduce, potential fix(es). | ||
| 2. The developer creates a PR. They should tag the related issue in the PR description | ||
| 3. The maintainer labels the PR (//TODO with what?), reviews it and decides if there is need for another pair of eyes on the PR. e.g. Some PRs may warrant someone from an area of expertise to review it. It could also be based on complexity, security, or breaking changes. | ||
| 4. If all looks good, maintainer merges the PR. If the PR changes some behavior that should be added/updated in end user documentation, the maintainer should add documentation pending label to the issue and keep it open. Remove the label once documentation PR is added and merged. |
There was a problem hiding this comment.
We do squash merge, should call that out (I don't like it).
There was a problem hiding this comment.
I have recently noticed the quality of commit messages is not great, opened a forum issue about this, but perhaps we could add in this section that there should always be a descriptive commit message?
There is a stark difference comparing commit messages prior to the fork to the ones in main since the fork.
There was a problem hiding this comment.
opened #851 in reference to my comment
Signed-off-by: CEHENKLE <[email protected]>
|
✅ Gradle Wrapper Validation success d73a27b |
|
✅ DCO Check Passed d73a27b |
|
✅ Gradle Precommit success d73a27b |
|
|
||
| OpenSearch and OpenSearch Dashboards will release major version together. They will NOT synchronize minor release — whenever the team feels they’re ready to release a minor version or patch (modulo the schedule above), they should release. | ||
|
|
||
| What we guarantee is that any major release of Dashboards is compatible with the same major release of OpenSearch. For example: 3.2.1 of Dashboards will work with 3.0.4 of OpenSearch, but 2.3.1 of Dashboards is not guaranteed to work with 3.0.4 of OpenSearch |
There was a problem hiding this comment.
What about the opposite?
Will an OpenSearch-Dashboards v3.2.1 be compatible with OpenSearch v2.0.1?
|
We've been iterating on org-wide docs. I think I want to thin out the ones in this repo and start pointing to the ones in https://github.com/opensearch-project/.github like in #853. @CEHENKLE you're cool with this? Want to port this content into RELEASING in .github? |
|
I'm going to close this out because much of the other notes have been folded into #853 Let's go take a look at those. |
Description
Adding information for maintainers about the role.
Issues Resolved
#95
#684
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.