Added more content (more to do)

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

@@ -0,0 +1,18 @@
++++
+title = "End-of-Life (EOL) Packages"
+description = ""
+gh_repo = "habitat"
+
+[menu]
+  [menu.habitat]
+    title = "End-of-Life (EOL) Packages"
+    identifier = "habitat/packages/support/package_support/end_of_life_eol_packages"
+    parent = "habitat/packages/package_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 are excluded from new 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 will not 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 will not receive support or be recommended for active use.
+
+This strategy ensures that deprecations do not 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

@@ -0,0 +1,19 @@
++++
+title = "Maintenance cycles"
+description = ""
+gh_repo = "habitat"
+
+[menu]
+  [menu.habitat]
+    title = "Maintenance cycles"
+    identifier = "habitat/packages/support/package_support/maintenance_cycles"
+    parent = "habitat/packages/package_support"
+    weight = 14
++++
+
+Package version refreshes are classified into the following maintenance cycles:
+
+- Single major, one minor (so)
+- Single major, multiple minor (sm)
+- Multiple major, one minor (mo)
+- Multiple major, multiple minor (mm)

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

@@ -0,0 +1,33 @@
++++
+title = "Package naming conventions"
+description = ""
+gh_repo = "habitat"
+
+[menu]
+  [menu.habitat]
+    title = "Package naming conventions"
+    identifier = "habitat/packages/support/package_support/package_naming_conventions"
+    parent = "habitat/packages/package_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.
+
+When only one major version of the package is supported, the following guidelines should be followed:
+
+- 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).
+
+- 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):
+  - 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. Resulting in Version X.Y having a breaking change versus X.Z
+Example: core/foo3_0, core/ foo3_1, core/ foo3_2, and/or core/foo3_3
+{{< /note >}} 

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

@@ -0,0 +1,48 @@
++++
+title = "Release channels"
+description = ""
+gh_repo = "habitat"
+
+[menu]
+  [menu.habitat]
+    title = "Release channels"
+    identifier = "habitat/packages/support/package_support/release_channels"
+    parent = "habitat/packages/package_support"
+    weight = 11
++++
+
+## 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.
+
+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.
+
+Overall, the LTS Channel provides a reliable and consistent environment for users, ensuring long-term support and stability for their applications and deployments.
+
+## Innovation release channel
+
+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.
+
+## 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.
+
+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.
+
+## Stable channels
+
+The stable channels in the Habitat multi-channel approach refer to the channels that have a known and declared lifecycle and rules. These channels are divided into two categories: LTS releases and Innovation releases.
+
+With the release of the first multi-channel refresh (LTS-2024), the stable channel in the core origin will be deprecated due to the presence of multiple legacy, unsupported, and end-of-life packages. The stable channel will remain active until a specified date to provide Habitat users with sufficient time to upgrade their workflows and adapt to the new approach.
+
+Following its deprecation, the stable channel will no longer be under active development or maintenance and will eventually reach end-of-life status.
+
+Once the stable channel of the core origin is declared end-of-life, no further updates will be provided for the packages in that channel for any reason. However, the channel will continue to exist until the end-of-life period for Habitat version 1.x has concluded. After this period, all packages will be removed from the stable channel.

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

@@ -0,0 +1,19 @@
++++
+title = "Syncing packages to the on-prem builder"
+description = ""
+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"
+    parent = "habitat/packages/package_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. If proceeding with the script:
+   1. Those packages will be demoted to the unstable channel.
+   1. Points to the new channel (for example, LTS-YYYY or Innovation-YYYY) for downloading packages from the Public Builder and uploading them to their respective on-prem builders.