Skip to content
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

Repo maintenance #6

Merged
merged 4 commits into from
Feb 19, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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.