Merge pull request kubernetes-retired#304 from adrianludwin/docs

Update docs for v1.1

Author: k8s-ci-robot

README.md

@@ -10,8 +10,9 @@ my-team
 Hierarchical namespaces make it easier to share your cluster by making
 namespaces more powerful. For example, you can create additional namespaces
 under your team's namespace, even if you don't have cluster-level permission to
-create namespaces, and easily apply policies like RBAC and Network Policies
-across all namespaces in your team (e.g. a set of related microservices).
+create namespaces, and easily apply policies like RBAC, Network Policies, and
+(beta in v1.1) hierarchical resource quotas across all namespaces in your team
+(e.g. a set of related microservices).
 
 Learn more in the [HNC User Guide](docs/user-guide) or get started with the
 instructions below!
@@ -27,8 +28,6 @@ Lead developer: @adrianludwin ([email protected])
 To install HNC on your cluster, and the `kubectl-hns` plugin on your
 workstation, follow the instructions on our [release
 pages](https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/).
-Note that versions of HNC prior to HNC v0.9 are available from our [old
-repo](https://github.com/kubernetes-sigs/multi-tenancy/releases/).
 
 Once HNC is installed, you can try out the [HNC
 quickstart](docs/user-guide/quickstart.md)
@@ -43,14 +42,17 @@ feature requests will be prioritized and assigned to a milestone or backlog.
 All HNC issues are assigned to an HNC milestone. So far, the following
 milestones are defined or planned:
 
+* [v1.2](https://github.com/kubernetes-sigs/hierarchical-namespaces/milestone/5):
+  HRQ to GA; server-side listing; stability improvements (ETA late 2023)
 * [v1.1](https://github.com/kubernetes-sigs/hierarchical-namespaces/milestone/3):
-  Hierarchical quotas; inclusive propagation.
+  Hierarchical quotas; inclusive propagation (released June 23 2023)
 * [v1.0](https://github.com/kubernetes-sigs/hierarchical-namespaces/milestone/2):
   HNC recommended for production use (released March 31 2022)
-* [v0.9](https://github.com/kubernetes-sigs/hierarchical-namespaces/milestone/1):
-  move HNC to its own repo; continued stability improvements.
-* [v0.1-v0.8](https://github.com/kubernetes-sigs/multi-tenancy/milestones):
-  see our old repo for details.
+
+### Older versions
+
+That versions of HNC prior to HNC v0.9 are available from our [old
+repo](https://github.com/kubernetes-sigs/multi-tenancy/releases/).
 
 ## Contact and governance
 

docs/releasing.md

@@ -35,9 +35,7 @@ that anyone can use, but without leaking personal access tokens._
 ## Document new/changed features
 
 Ensure that the [user guide](user-guide/) is up-to-date with all the latest or
-changed features. _This must be done on the master branch **before** creating
-the release branch._ We used to remove instructions for old versions of HNC, but
-since v1.0 this should no longer be necessary as it's not changing as quickly.
+changed features.
 
 ## Create a release branch
 
@@ -137,15 +135,14 @@ warning. If this was a release candidate, you're done.
 Otherwise, update the [README](../README.md#start) and [user
 guide](user-guide/how-to.md#admin-install) to refer to your new release.
 
-If this was a patch release _and you need to document something_, ensure you
-document it on _both_ the master _and_ the release branch.
+As of HNC v1.0, there is no need to update the docs on the branches.
 
 ## Update Krew
 
-Starting with HNC v0.6.x, the build process also generates a Krew tarball and
+The build process also generates a Krew tarball and
 manifest. This manifest should be downloaded and checked into the Krew index,
 *if* it's for the latest branch (and is not a release candidate). E.g. if you've
-already released HNC v0.7.0 and have to release HNC v0.6.1, do *not* update the
+already released HNC v1.1.0 and have to release HNC v1.0.1, do *not* update the
 Krew index; Krew can only support one version of a plugin at a time so we should
 only support the most recent branch.
 

docs/user-guide/README.md

@@ -1,4 +1,4 @@
-# HNC User Guide v1.1
+# HNC User Guide
 
 Authors: [email protected] and other contributors from wg-multitenancy
 
@@ -12,23 +12,10 @@ This guide explains how to use hierarchical namespaces, explains some of the
 concepts behind them for a more in-depth understanding, and covers some best
 practices.
 
-**Note: this doc covers HNC v1.0 and later.** For older versions of HNC, see
-below.
-
 ## Table of contents
 
 * [Quickstart](quickstart.md): Quickly get going with HNC
 * [How-to](how-to.md): Perform common tasks when working with HNC
 * [Concepts](concepts.md): Learn more about the ideas behind HNC
 * [Best practices](best-practices.md): learn about the best ways to deploy HNC
 * [FAQs](faq.md): contact us, requirements, limitations and whatnot
-
-## Older user guides
-
-* [HNC v0.9](https://github.com/kubernetes-sigs/hierarchical-namespaces/tree/hnc-v0.9/docs/user-guide)
-* [HNC v0.8](https://github.com/kubernetes-sigs/multi-tenancy/tree/hnc-v0.8/incubator/hnc/docs/user-guide)
-* [HNC v0.7](https://github.com/kubernetes-sigs/multi-tenancy/tree/hnc-v0.7/incubator/hnc/docs/user-guide)
-* [HNC v0.6](https://github.com/kubernetes-sigs/multi-tenancy/tree/hnc-v0.6/incubator/hnc/docs/user-guide)
-* [HNC v0.5](https://github.com/kubernetes-sigs/multi-tenancy/tree/hnc-v0.5/incubator/hnc/docs/user-guide)
-* [HNC v0.4](https://github.com/kubernetes-sigs/multi-tenancy/tree/hnc-v0.4/incubator/hnc/docs/user-guide)
-* [HNC v0.3](https://docs.google.com/document/d/1XVVv1ha4j1WUaszu3mmlACeWPUJXbJhA6zntxswrsco)

docs/user-guide/how-to.md

@@ -492,9 +492,6 @@ namespace will be silently ignored. This will eventually
 
 ### Install or upgrade HNC on a cluster
 
-HNC requires Kubernetes v1.16 or later, since it relies on APIs (such as CRDs
-and webhooks) that were only introduced in v1.16.
-
 There is no need to uninstall HNC before upgrading it unless specified in the
 release notes for that version.
 
@@ -988,4 +985,4 @@ Interesting parameters include:
   exclude an object from propagation.
     * Rancher objects that have the label `cattle.io/creator=norman` are not propagated
     by the default manifests (refer to [Concepts: built in exceptions](concepts.md#built-in-exceptions)
-    for more information).
+    for more information).