From df04c2f9faf4cc7b989094cdbe4e4347fee4dd10 Mon Sep 17 00:00:00 2001 From: Sean Molenaar Date: Tue, 27 Apr 2021 16:36:39 +0200 Subject: [PATCH 1/2] docs: clarify upstream versions requirement --- docs/Versions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Versions.md b/docs/Versions.md index 0b0ae43a84..3a08b6f6d4 100644 --- a/docs/Versions.md +++ b/docs/Versions.md @@ -8,7 +8,7 @@ Versioned formulae we include in [homebrew/core](https://github.com/homebrew/hom * Versioned software should build on all Homebrew's supported versions of macOS. * Versioned formulae should differ in major/minor (not patch) versions from the current stable release. This is because patch versions indicate bug or security updates, and we want to ensure you apply security updates. * Unstable versions (alpha, beta, development versions) are not acceptable for versioned (or unversioned) formulae. -* Upstream should have a release branch for each formula version, and release security updates for each version when necessary. For example, [PHP 7.0 was not a supported version but PHP 7.2 was](https://php.net/supported-versions.php) in January 2020. By contrast, most software projects are structured to only release security updates for their latest versions, so their earlier versions are not eligible for versioning. +* Upstream should have a release branch for each formula version, and claim to release security updates for each version when necessary. For example, [PHP 7.0 was not a supported version but PHP 7.2 was](https://php.net/supported-versions.php) in January 2020. By contrast, most software projects are structured to only release security updates for their latest versions, so their earlier versions are not eligible for versioning. * Versioned formulae should share a codebase with the main formula. If the project is split into a different repository, we recommend creating a new formula (`formula2` rather than `formula@2` or `formula@1`). * Formulae that depend on versioned formulae must not depend on the same formulae at two different versions twice in their recursive dependencies. For example, if you depend on `openssl@1.0` and `foo`, and `foo` depends on `openssl` then you must instead use `openssl`. * Versioned formulae should only be linkable at the same time as their non-versioned counterpart if the upstream project provides support for it, e.g. using suffixed binaries. If this is not possible, use `keg_only :versioned_formula` to allow users to have multiple versions installed at once. From 88cf8681a3df0010b21befc3b7b7cd95e1d43d07 Mon Sep 17 00:00:00 2001 From: Sean Molenaar Date: Tue, 27 Apr 2021 16:43:54 +0200 Subject: [PATCH 2/2] docs: rename version claim to policy Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com> --- docs/Versions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Versions.md b/docs/Versions.md index 3a08b6f6d4..bc9da96576 100644 --- a/docs/Versions.md +++ b/docs/Versions.md @@ -8,7 +8,7 @@ Versioned formulae we include in [homebrew/core](https://github.com/homebrew/hom * Versioned software should build on all Homebrew's supported versions of macOS. * Versioned formulae should differ in major/minor (not patch) versions from the current stable release. This is because patch versions indicate bug or security updates, and we want to ensure you apply security updates. * Unstable versions (alpha, beta, development versions) are not acceptable for versioned (or unversioned) formulae. -* Upstream should have a release branch for each formula version, and claim to release security updates for each version when necessary. For example, [PHP 7.0 was not a supported version but PHP 7.2 was](https://php.net/supported-versions.php) in January 2020. By contrast, most software projects are structured to only release security updates for their latest versions, so their earlier versions are not eligible for versioning. +* Upstream should have a release branch for each formula version, and have an explicit policy of releasing security updates for each version when necessary. For example, [PHP 7.0 was not a supported version but PHP 7.2 was](https://php.net/supported-versions.php) in January 2020. By contrast, most software projects are structured to only release security updates for their latest versions, so their earlier versions are not eligible for versioning. * Versioned formulae should share a codebase with the main formula. If the project is split into a different repository, we recommend creating a new formula (`formula2` rather than `formula@2` or `formula@1`). * Formulae that depend on versioned formulae must not depend on the same formulae at two different versions twice in their recursive dependencies. For example, if you depend on `openssl@1.0` and `foo`, and `foo` depends on `openssl` then you must instead use `openssl`. * Versioned formulae should only be linkable at the same time as their non-versioned counterpart if the upstream project provides support for it, e.g. using suffixed binaries. If this is not possible, use `keg_only :versioned_formula` to allow users to have multiple versions installed at once.