Skip to content

Commit

Permalink
Repo maintenance (#6)
Browse files Browse the repository at this point in the history
* Add Initial Repo Maintenance Files.

Signed-off-by: Rajvaibhav Rahane <[email protected]>

* add github templates, workflows, codeowners

Signed-off-by: Rajvaibhav Rahane <[email protected]>

* Add RELEASING.md and .codecov.yml

Signed-off-by: Rajvaibhav Rahane <[email protected]>

---------

Signed-off-by: Rajvaibhav Rahane <[email protected]>
  • Loading branch information
Rajrahane authored Feb 19, 2025
1 parent cb3032d commit 0990268
Show file tree
Hide file tree
Showing 2 changed files with 58 additions and 0 deletions.
15 changes: 15 additions & 0 deletions .codecov.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
codecov:
require_ci_to_pass: yes

coverage:
precision: 2
round: down
range: "70...100"
status:
project:
default:
target: 80% # the required coverage value
threshold: 2% # the leniency in hitting the target

ignore:
- '**/tests/*.py'
43 changes: 43 additions & 0 deletions RELEASING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
- [Overview](#overview)
- [Branching](#branching)
- [Single Repo Artifacts Branching](#single-repo-artifacts-branching)
- [Feature Branches](#feature-branches)
- [Versioning](#versioning)
- [Version Numbers](#version-numbers)
- [Remote-Vector-Index-Build-Service Version Numbers](#remote-vector-index-build-service-version-numbers)
- [Tagging](#tagging)
- [Release Labels](#release-labels)

## Overview

This document explains the release strategy for artifacts in the remote-vector-index-service-worker.

## Branching

Projects create a new branch when they need to start working on 2 separate versions of the product, with the `main` branch being the furthermost release.

### Single Repo Artifacts Branching

For the initial first release, remote-vector-index-build-service follows a simpler branching model with the next release always living on `main` and no patch branches.

### Feature Branches

Do not creating branches in the upstream repo, use your fork, for the exception of long lasting feature branches that require active collaboration from multiple developers. Name feature branches `feature/<thing>`. Once the work is merged to `main`, please make sure to delete the feature branch.

## Versioning

All distributions in this organization [follow SemVer](https://opensearch.org/blog/technical-post/2021/08/what-is-semver/). A user-facing breaking change can only be made in a major release. Any regression that breaks SemVer is considered a high severity bug.

### Version Numbers

#### Remote-Vector-Index-Build-Service Version Numbers

The build number of the service is 3-digit `major.minor.patch` (e.g. `1.9.0`)

### Tagging

Create tags after a release that match the version number, `major.minor.patch`, without a `v` prefix.

### Release Labels

Repositories create consistent release labels, such as `v1.0.0`, `v1.1.0` and `v2.0.0`. Use release labels to target an issue or a PR for a given release. See [MAINTAINERS](MAINTAINERS.md#triage-open-issues) for more information on triaging issues.

0 comments on commit 0990268

Please sign in to comment.