Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

docs: Reword conda-forge section mentioning libevent-2.1.10 #905

Merged
merged 1 commit into from
Sep 27, 2023
Merged

docs: Reword conda-forge section mentioning libevent-2.1.10 #905

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
55 changes: 37 additions & 18 deletions docs/mkdocs/docs/technical/releasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,34 +49,53 @@ The [build will now be running for the tag.](https://github.com/man-group/Arctic

A new release on conda-forge is made by creating a Pull Request on the feedstock of ArcticDB: [`conda-forge/arcticdb-feedstock`](https://github.com/conda-forge/arcticdb-feedstock).

If you have created a tag on ArcticDB's repository, [`regro-cf-autotick-bot`](https://github.com/regro-cf-autotick-bot)
For more information about conda-forge release process and feedstocks' maintenance,
see [this section of the documentation of conda-forge](https://conda-forge.org/docs/maintainer/updating_pkgs.html).

If you have created a tag for a release on ArcticDB's repository, [`regro-cf-autotick-bot`](https://github.com/regro-cf-autotick-bot)
might already have opened a Pull Request to create a new release.
You can update such a PR or create a new one to release a version, updating the conda recipe.
You can push commit to this PR or alternatively create a new PR to release a version.

> [!IMPORTANT]
> **Do not commit directly to the feedstock repository.**
> Commits to the repository release new versions to conda-forge. Instead, changes must be made
> Commits to the repository release new versions to conda-forge. Instead, changes **must** be made
via personal forks or via the PR created by the [`regro-cf-autotick-bot`](https://github.com/regro-cf-autotick-bot) as mentioned above.

> [!IMPORTANT]
> If publishing a release-candidate (AKA pre-release version), you **must** branch from `rc` and merge the created PR into the `rc` branch.
> This will require modifying the base branch of the created PR.
> If publishing a normal release, you **must** branch of `main` and merge the created PR into the `main` branch.

You will need to update:
> If publishing a normal release, you **must** create two pull-requests due to some users' constraints
> (see the description of the introduction of the `libevent-2.1.10` branch in
> [this PR](https://github.com/conda-forge/arcticdb-feedstock/pull/64) for more context):
> - one pull request which branch from `main` and merge the created PR into the `main` branch.
> - one pull request which branch from `libevent-2.1.10` and merge the created PR into the `libevent-2.1.10` branch.
> This will require modifying the base branch of the created PR from `main` to `libevent-2.1.10`.

1. `version`, pointing to the tag created in step 1
2. The `sha256sum` of the source tarball
3. The build number (i.e. `number` under the `build` section) to `0`
4. Dependencies (if they have changed since the last version, see `setup.cfg`)
5. Rerender the feedstock's recipe to create Azure CI jobs' specification for all variants of the package

A PR is generally open with a todo-list summarizing all the required steps to perform,
> [!IMPORTANT]
> If publishing a release-candidate (AKA pre-release), you **must** branch from `rc` and merge the created PR into the `rc` branch.
> This will require modifying the base branch of the created PR from `main` to `rc`.

For each PR, the following steps are required:
1. [Fork `regro-cf-autotick-bot`](https://github.com/conda-forge/arcticdb-feedstock/fork)
2. Create a branch of the base branch for your case (see above)
3. Change [`recipe/meta.yaml`](https://github.com/conda-forge/arcticdb-feedstock/blob/main/recipe/meta.yaml)
to update the following pieces of information:
- `version`, pointing to the tag created in step 1
- `sha256sum` of the source tarball
- the build number (i.e. `number` under the `build` section) to `0`
- the dependencies if they have changed since the last version in:
- [`setup.cfg`](https://github.com/man-group/ArcticDB/blob/master/setup.cfg)
- [`environment_unix.yml`](https://github.com/man-group/ArcticDB/blob/master/environment_unix.yml)
4. Push on your fork and create a PR to the feedstock targeting the base branch on `conda-forge/arcticdb`
5. Rerender the feedstock's recipe to create Azure CI jobs' specification for all variants of the package
This can be done by posting a comment on the PR with the following content `@conda-forge-admin, please rerender`

A PR is generally open with a TODO-list summarizing all the required steps to perform,
before an update to the feedstock.

Here are for example:
- [the PR used to publish `1.3.0`](https://github.com/conda-forge/arcticdb-feedstock/pull/10), a normal release
- [the PR used to publish `3.0.0rc1`](https://github.com/conda-forge/arcticdb-feedstock/pull/55), a release candidate
Example of pull-requests:
- for normal release:
- [the PR used to publish `4.0.0` which targets `main`](https://github.com/conda-forge/arcticdb-feedstock/pull/67)
- [the PR used to publish `4.0.0` which targets `libevent-2.1.10`](https://github.com/conda-forge/arcticdb-feedstock/pull/68)
- for a release candidate: [the PR used to publish `3.0.0rc1` with targets `rc`](https://github.com/conda-forge/arcticdb-feedstock/pull/55)

## 3. Release to PyPi

Expand Down