chore: update to JOSDK 5.0.0-beta1

Signed-off-by: Chris Laprun <[email protected]>
quarkiverse · Dec 17, 2024 · 43cf27d · 43cf27d
1 parent 742bcff
commit 43cf27d
Show file tree

Hide file tree

Showing 3 changed files with 1 addition and 5 deletions.
diff --git a/docs/modules/ROOT/pages/includes/quarkus-operator-sdk.adoc b/docs/modules/ROOT/pages/includes/quarkus-operator-sdk.adoc
@@ -469,8 +469,6 @@ An optional list of comma-separated watched namespace names that will be used to
 
 Note that this is provided as a means to quickly deploy a specific controller to test it by applying the generated manifests to the target cluster. If empty, no manifests will be generated. The namespace in which the controller will be deployed will be the currently configured namespace as specified by your `.kube/config` file, unless you specify the target deployment namespace using the `quarkus.kubernetes.namespace` property.
 
-
-
 As this functionality cannot handle namespaces that are not know until runtime (because the generation happens during build time), we recommend that you use a different mechanism such as OLM or Helm charts to deploy your operator in production.
 
 This replaces the previous `namespaces` property which was confusing and against Quarkus best practices since it existed both at build time and runtime. That property wasn't also adequately capturing the fact that namespaces that wouldn't be known until runtime would render whatever got generated at build time invalid as far as generated manifests were concerned.

diff --git a/docs/modules/ROOT/pages/includes/quarkus-operator-sdk_quarkus.operator-sdk.adoc b/docs/modules/ROOT/pages/includes/quarkus-operator-sdk_quarkus.operator-sdk.adoc
@@ -469,8 +469,6 @@ An optional list of comma-separated watched namespace names that will be used to
 
 Note that this is provided as a means to quickly deploy a specific controller to test it by applying the generated manifests to the target cluster. If empty, no manifests will be generated. The namespace in which the controller will be deployed will be the currently configured namespace as specified by your `.kube/config` file, unless you specify the target deployment namespace using the `quarkus.kubernetes.namespace` property.
 
-
-
 As this functionality cannot handle namespaces that are not know until runtime (because the generation happens during build time), we recommend that you use a different mechanism such as OLM or Helm charts to deploy your operator in production.
 
 This replaces the previous `namespaces` property which was confusing and against Quarkus best practices since it existed both at build time and runtime. That property wasn't also adequately capturing the fact that namespaces that wouldn't be known until runtime would render whatever got generated at build time invalid as far as generated manifests were concerned.

diff --git a/pom.xml b/pom.xml
@@ -13,7 +13,7 @@
   <name>Quarkus - Operator SDK - Parent</name>
   <properties>
     <quarkus.version>3.17.4</quarkus.version>
-    <java-operator-sdk.version>5.0.0-SNAPSHOT</java-operator-sdk.version>
+    <java-operator-sdk.version>5.0.0-beta1</java-operator-sdk.version>
   </properties>
   <scm>
     <connection>:git:[email protected]:quarkiverse/quarkus-operator-sdk.git</connection>
Original file line number	Diff line number	Diff line change
Expand Up		@@ -469,8 +469,6 @@ An optional list of comma-separated watched namespace names that will be used to

		Note that this is provided as a means to quickly deploy a specific controller to test it by applying the generated manifests to the target cluster. If empty, no manifests will be generated. The namespace in which the controller will be deployed will be the currently configured namespace as specified by your `.kube/config` file, unless you specify the target deployment namespace using the `quarkus.kubernetes.namespace` property.



		As this functionality cannot handle namespaces that are not know until runtime (because the generation happens during build time), we recommend that you use a different mechanism such as OLM or Helm charts to deploy your operator in production.

		This replaces the previous `namespaces` property which was confusing and against Quarkus best practices since it existed both at build time and runtime. That property wasn't also adequately capturing the fact that namespaces that wouldn't be known until runtime would render whatever got generated at build time invalid as far as generated manifests were concerned.
Expand Down