Editing

Signed-off-by: Ian Maddaus <[email protected]>

components/docs-chef-io/config.toml

@@ -33,6 +33,12 @@ identifier = "habitat"
   parent = "habitat"
   weight = 40
 
+    [[menu.habitat]]
+    title = "Package support"
+    identifier = "habitat/packages/support"
+    parent = "habitat/packages"
+    weight = 10
+
   [[menu.habitat]]
   title = "Plans"
   identifier = "habitat/plans"

components/docs-chef-io/content/habitat/package_support.md

@@ -1,12 +0,0 @@
-+++
-title = "Habitat package support policy"
-description = ""
-gh_repo = "habitat"
-
-[menu]
-  [menu.habitat]
-    title = "Package support policy"
-    identifier = "habitat/packages/support"
-    parent = "habitat/packages"
-    weight = 10
-+++

components/docs-chef-io/content/habitat/overview.md → components/docs-chef-io/content/habitat/package_support/_index.md

@@ -1,6 +1,8 @@
 +++
-title = "Overview"
-description = ""
+title = "Habitat package support policy"
+
+linkTitle = "Package support policy"
+
 gh_repo = "habitat"
 
 [menu]
@@ -15,7 +17,12 @@ Refer to the following sections for details about the current approach, its limi
 
 ## Current approach and limitations
 
-All Habitat packages in the core origin are regularly refreshed and released to the stable channel. Best practice is to use packages from the stable channel. Initially, the stable channel was designed for consistent stability across packages. However, this model is less effective for core libraries, which require specific lifecycle policies. No packages are removed - packages that cannot be refreshed due to incompatibility or build issues are simply skipped.
+In the past, all Habitat packages in the core origin were regularly refreshed and released to the stable channel
+and the best practice was to use packages from this channel.
+Initially, the stable channel was designed for consistent stability across packages.
+
+However, this model is less effective for core libraries which require specific lifecycle policies.
+Packages weren't removed and packages that can't be refreshed due to incompatibility or build issues were simply skipped.
 
 - Deprecation or relegation of packages and major version upgrades can cause potential disruption to existing applications or installations.
 - Only security fixes that have a minor impact can be included. The current model prevents the deprecation or removal of outdated packages and limits the inclusion of significant security fixes or major version updates. This could lead to risks when using pinned packages because they might not upgrade to more secure versions.
@@ -35,12 +42,15 @@ The new multi-channel approach for Habitat packages introduces Long-Term Support
 - **Sync scripts:** Sync scripts to sync packages from core, chef, and chef-platform origins from LTS-YYYY and Innovation-YYYY channels from Public Builder to On Prem Builder.
 - **Maintenance cycles:** Each core package will have an associated maintenance cycle during a package refresh to help identify whether or not multiple majors or minors for that project are available.
 - **Package naming conventions:** Packages will follow specific naming conventions based on their versioning schema, ensuring consistency and reliability in updates.
-- **Origins impacted:** core, chef and chef-platform.
+- **Origins impacted:** core, chef, and chef-platform.
 
     {{< note >}}
+
     Chef 360 skills under chef-platform origin are currently in the stable channel. They will be moved to the LTS-2024 channel soon.
+
     {{< /note >}}
-- **Build function on public builder:** The build function on the SaaS builder will be disabled because building from stable by default does not align with a multi-channel approach.
+
+- **Build function on public builder:** The build function on the SaaS builder will be disabled because building from stable by default doesn't align with a multi-channel approach.
 - **Package intake process:** If a Habitat user wants to have a new package added to the core origin, the following points apply:
   - This must be requested in the form of an Aha Idea.
-  - If the requested package meets the Support and Usage Threshold, these requests will be considered alongside other feature requests during planning periods.
+  - If the requested package meets the [support and usage threshold](thresholds), these requests will be considered alongside other feature requests during planning periods.

components/docs-chef-io/content/habitat/package_support/eol.md

@@ -0,0 +1,22 @@
++++
+title = "End-of-life (EOL) packages"
+
+gh_repo = "habitat"
+
+[menu]
+  [menu.habitat]
+    title = "EOL packages"
+    identifier = "habitat/packages/support/end_of_life_eol_packages"
+    parent = "habitat/packages/support"
+    weight = 12
++++
+
+End-of-life (EOL) packages refer to packages that have reached the end of their support lifecycle.
+These packages are no longer maintained or updated, and they're excluded from long-term support (LTS) releases to minimize disruption for users.
+
+For example, if a package like core/openssl11 reaches the end of its support lifecycle, it won't be included in the subsequent LTS release channel.
+This approach allows customers to transition to the latest LTS channel at their convenience while maintaining the previous LTS channel,
+including the older packages for those who need them.
+However, the older packages won't receive support or be recommended for active use.
+
+This strategy ensures that deprecations don't adversely affect customers, granting the package management team the flexibility to implement significant changes without disrupting user workflows.

components/docs-chef-io/content/habitat/maintenance_cycles.md → components/docs-chef-io/content/habitat/package_support/maintenance_cycles.md

@@ -1,12 +1,12 @@
 +++
 title = "Maintenance cycles"
-description = ""
+
 gh_repo = "habitat"
 
 [menu]
   [menu.habitat]
     title = "Maintenance cycles"
-    identifier = "habitat/packages/support/package_support/maintenance_cycles"
+    identifier = "habitat/packages/support/maintenance_cycles"
     parent = "habitat/packages/support"
     weight = 14
 +++

components/docs-chef-io/content/habitat/package_naming_conventions.md → components/docs-chef-io/content/habitat/package_support/naming.md

@@ -1,42 +1,47 @@
 +++
-title = "Package naming conventions"
-description = ""
+title = "Habitat package naming conventions"
+
 gh_repo = "habitat"
 
 [menu]
   [menu.habitat]
-    title = "Package naming conventions"
-    identifier = "habitat/packages/support/package_support/package_naming_conventions"
+    title = "Naming conventions"
+    identifier = "habitat/packages/support/package_naming_conventions"
     parent = "habitat/packages/support"
     weight = 14
 +++
 
-Each package is identified by a unique string containing four sub-strings separated by a forward slash (/) called a PackageIdent (origin/name/version/release). This naming convention refers only to packages in the core origin.
+Each package in the core origin is identified by a unique string---called a package ident---in the following format: origin/name/version/release
 
-When only one major version of the package is supported, the following guidelines should be followed:
+When only one major version of a package is supported, use the following guidelines:
 
 - The value of **name** should exactly match the name of the project it represents.
 - The plan file should be located within a directory of the same name in this repository. For example, a single refresh will only maintain one major version of glibc and (as such) the package name will be core/glibc with no suffix.
 
-When more than one major version of the package will be supported, the project uses Semantic Versioning (SemVer).
+When more than one major version of the package will be supported, the project uses semantic versioning (SemVer).
 
 - If the project honors SemVer (only breaking changes occur in major releases):
+
   - The value of **name** should match the name of the project it represents, plus the major version of the package being supported (as a suffix).
   - The plan file should be located within a directory of the same name (including the suffix) in this repository. For example, core/postgresql16 and/or core/postgresql17.
-- If the project does not honor SemVer (referred to as Romantic Versioning or RomVer):
+
+- If the project doesn't honor SemVer (referred to as Romantic Versioning or RomVer):
+
   - The value of **name** should match the name of the project it represents, plus the major and minor version of the package being supported (as a suffix).
   - The plan file should be located within a directory of the same name (including the suffix) in this repository.
 
   {{< note >}}
+
   Romantic versions appear like a SemVer in format but may/can/will introduce breaking changes as part of a “minor” update. This results in Version X.Y having a breaking change versus X.Z.
+
   {{< /note >}}
 
   For example, core/foo3_0, core/ foo3_1, core/ foo3_2, and/or core/foo3_3.
 
-- If the project does not use SemVer:
-  For example, builder-api, perl.
-  The packages will be reviewed package to package and refresh to refresh.
+- If a project doesn't use SemVer, for example builder-api or perl, the package will be reviewed from package to package and refresh to refresh.
 
 {{< note >}}
-Even though a package name may be altered to include a major (and minor) version suffix, package versions are never altered from their project's source. For example, if the package uses a DateVer schema where it is YYYYMMDD, this will not be reformatted to YYYY.MM.DD. This is to ensure the CVE detection process and automated build and detection systems can refer to the exact publishers' versions.
+
+Even though a package name may be altered to include a major (and minor) version suffix, package versions are never altered from their project's source. For example, if the package uses a DateVer schema where it is YYYYMMDD, this won't be reformatted to YYYY.MM.DD. This is to ensure the CVE detection process and automated build and detection systems can refer to the exact publishers' versions.
+
 {{< /note >}}

components/docs-chef-io/content/habitat/release_channels.md → components/docs-chef-io/content/habitat/package_support/release_channels.md

@@ -1,6 +1,6 @@
 +++
-title = "Release channels"
-description = ""
+title = "Habitat package release channels"
+
 gh_repo = "habitat"
 
 [menu]
@@ -13,15 +13,15 @@ gh_repo = "habitat"
 
 Refer to the following sections for details about the various release channels.
 
-## Long Term Support (LTS) channel
+## Long term support (LTS) channel
 
 The LTS Channel (designated as LTS-YYYY where YYYY indicates the year of release) is designed to provide a stable environment with the latest refreshed packages that will be supported for three years. LTS releases aim to ensure compatibility and updates over a multi-year period.
 
 The initial LTS-YYYY release may involve breaking changes due to major upgrades and the removal of end-of-life packages. However, subsequent releases within the channel will maintain stability and compatibility.
 
 LTS versions of Chef tools (such as Chef Infra 19) will be available under chef origin in the LTS-YYYY channel. These tools will be built from packages in the core origin from the LTS-YYYY channel.
 
-To retain older versions of packages once they are updated in LTS-YYYY, a corresponding unstable channel (for example, LTS-YYYY-unstable) will be created. This approach ensures that deprecated packages are excluded from new LTS releases, minimizing disruption for users.
+To retain older versions of packages once they're updated in LTS-YYYY, a corresponding unstable channel (for example, LTS-YYYY-unstable) will be created. This approach ensures that deprecated packages are excluded from new LTS releases, minimizing disruption for users.
 
 The LTS-YYYY channel will contain packages for common dependencies and compilers maintained by Chef, in addition to packages for Chef Infra Client, Chef InSpec, and other related tools.
 
@@ -31,11 +31,11 @@ Overall, the LTS Channel provides a reliable and consistent environment for user
 
 The innovation release channel (designated as Innovation-YYYY where YYYY indicates the year of release) contains the latest refreshed packages between two LTS releases. This channel may introduce breaking changes to prepare for the next LTS release. The support duration for an innovation channel is shorter than that of an LTS channel and is determined at the discretion of Progress Chef.
 
-The innovation channel is designed to provide users with access to the most recent updates and features, allowing them to test and adopt new changes before they are included in the next LTS release. This approach ensures that users can stay up-to-date with the latest advancements while also preparing for future LTS releases.
+The innovation channel is designed to provide users with access to the most recent updates and features, allowing them to test and adopt new changes before they're included in the next LTS release. This approach ensures that users can stay up-to-date with the latest advancements while also preparing for future LTS releases.
 
 ## Unstable channels
 
-The unstable channels are created to retain older versions of packages once they are updated in the LTS-YYYY or Innovation-YYYY channels. For each LTS and innovation channel, a corresponding unstable channel (for example, LTS-YYYY-unstable or Innovation-YYYY-unstable) is created.
+The unstable channels are created to retain older versions of packages once they're updated in the LTS-YYYY or Innovation-YYYY channels. For each LTS and innovation channel, a corresponding unstable channel (for example, LTS-YYYY-unstable or Innovation-YYYY-unstable) is created.
 
 These unstable channels ensure that deprecated packages are excluded from new LTS releases, minimizing disruption for users. This approach allows users to access older versions of packages if needed, while still benefiting from the latest updates and improvements in the stable channels.
 

components/docs-chef-io/content/habitat/syncing_packages_to_on_prem_builder.md → components/docs-chef-io/content/habitat/package_support/syncing_on_prem_builder.md

@@ -1,19 +1,19 @@
 +++
-title = "Syncing packages to the on-prem builder"
-description = ""
+title = "Syncing packages to the on-prem Habitat Builder"
+
 gh_repo = "habitat"
 
 [menu]
   [menu.habitat]
-    title = "Syncing packages to the on-prem builder"
-    identifier = "habitat/packages/support/package_support/syncing_packages_to_on_prem_builder"
+    title = "Syncing to on-prem Builder"
+    identifier = "habitat/packages/support/syncing_packages_to_on_prem_builder"
     parent = "habitat/packages/support"
     weight = 13
 +++
 
 A sync script will be provided that will:
 
-1. Perform a pre-flight check that returns a list of packages under core origin for that channel (for example, LTS-YYYY or Innovation-YYYY) that are not created/maintained by Progress Chef.
+1. Perform a pre-flight check that returns a list of packages under core origin for that channel (for example, LTS-YYYY or Innovation-YYYY) that aren't created or maintained by Progress Chef.
 1. If proceeding with the script:
    1. Those packages will be demoted to the unstable channel.
    1. Packages are downloaded from the channel specified (for example, LTS-YYYY or Innovation-YYYY) from Public Builder and uploaded to their respective on-prem builders.

components/docs-chef-io/content/habitat/package_support/thresholds.md

@@ -0,0 +1,31 @@
++++
+title = "Package support and usage thresholds"
+
+gh_repo = "habitat"
+
+[menu]
+  [menu.habitat]
+    title = "Support and usage thresholds"
+    identifier = "habitat/packages/support/support_and_usage_thresholds"
+    parent = "habitat/packages/support"
+    weight = 15
++++
+
+Refer to the following sections for details about the support and usage thresholds.
+
+## Support threshold
+
+Progress Chef supports packages that aren't dependencies for Progress Chef tools under the following conditions:
+
+- There isn't a published end-of-life (EOL) date within the first two years of the LTS-YYYY support duration at the time of consideration.
+  If the OEM drops support or doesn't provide a fix to known vulnerabilities during the LTS time frame, no updates will be made available.
+- There aren't any open high or critical CVEs for that package at the time of consideration.
+  If any released package has a critical or high CVE post-release, it will be fixed as part of the next minor or directed refresh.
+- It should have a valid licensing model that allows Progress Chef to distribute it as a Habitat Package.
+
+## Usage threshold
+
+A requested package will be added for backlog prioritization it if falls in one of the following categories:
+
+- It's commonly-used development tools or programming language
+- it's high-demand commercial off-the-shelf software