Merge pull request #617 from buildpacks/update-migration

Clarify and expand on implications of upgrading to Platform API 0.10

docs/index.html

@@ -958,7 +958,7 @@ <h2 id="toolsdocstools"><a href="/docs/tools/">Tools</a></h2>
 which allows users to run <a href="/docs/install-pack">pack</a> commands inside their pipelines.</li>
 <li><strong><a href="/docs/tools/gitlab">GitLab</a></strong> - <a href="https://about.gitlab.com/">Gitlab</a> is a web based DevOps platform. It uses <a href="/docs/install-pack"><code>pack</code></a> as part of the <a href="https://docs.gitlab.com/ee/topics/autodevops/">Auto DevOps</a> feature, to
 build applications prior to deploying them.</li>
-<li><strong><a href="/docs/tools/kpack">kpack</a></strong> - <a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform maintained by <a href="https://www.vmware.com/company.html">VMware</a> under the <a href="https://tanzu.vmware.com/build-service">VMware Tanzu project</a> that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</li>
+<li><strong><a href="/docs/tools/kpack">kpack</a></strong> - <a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform, belonging to the <a href="https://github.com/buildpacks-community">Buildpacks Community</a> organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</li>
 <li><strong><a href="/docs/tools/pack">Pack</a></strong> - Pack is a tool maintained by the Cloud Native Buildpacks project to support the use of buildpacks.</li>
 <li><strong><a href="/docs/tools/tekton">Tekton</a></strong> - <a href="https://tekton.dev/">Tekton</a> is an open-source CI/CD system platform implementation running on k8s. There are two Tekton <code>tasks</code>
 maintained by the CNB project, both of which use the <a href="/docs/concepts/components/lifecycle">lifecycle</a> directly (i.e. they do not use <code>pack</code>).</li>

docs/reference/spec/migration/buildpack-api-0.8-0.9/index.html

@@ -747,7 +747,7 @@ <h3 id="shell-removal">Shell removal</h3>
 <h3 id="overridable-process-arguments">Overridable process arguments</h3>
 <p>Hand-in-hand with shell removal is the introduction of overridable process arguments.</p>
 <p>In <code>launch.toml</code>, <code>command</code> is now a list. The first element in <code>command</code> is the command, and all following entries are arguments that are always provided to the process, regardless of how the application is started. The <code>args</code> list now designates arguments that can be overridden by the end user - if supported by the platform (Platform API version 0.10 and above). For further details, see the platform <a href="/docs/reference/spec/migration/platform-api-0.9-0.10">migration guide</a>.</p>
-<p>For older platforms (Platform API version 0.9 and below), arguments in <code>args</code> will be appended to arguments in <code>command</code>, negating the new functionality (but preserving compatibility).</p>
+<p>For older platforms (Platform API version 0.9 and below), arguments in <code>command</code> will be prepended to arguments in <code>args</code>, negating the new functionality (but preserving compatibility).</p>
 <h3 id="image-extensions-are-supported-experimental">Image extensions are supported (experimental)</h3>
 <p>Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see <a href="/docs/features/dockerfiles">here</a> for more information).</p>
 <p>For more information, see <a href="/docs/extension-guide/create-extension">authoring an image extension</a>.</p>

docs/reference/spec/migration/platform-api-0.9-0.10/index.html

@@ -754,17 +754,24 @@ <h4 id="newer-buildpacks">Newer buildpacks</h4>
 </code></pre><p>will result in the following command invocation: <code>some-command always-1 always-2 override-1 override-2</code>. However:</p>
 <pre tabindex="0"><code>docker run --entrypoint from-newer-buildpack my-image user-1 user-2
 </code></pre><p>will result in the following command invocation: <code>some-command always-1 always-2 user-1 user-2</code>.</p>
+<h4 id="implications-of-upgrading">Implications of upgrading</h4>
+<p>For processes from newer buildpacks, upgrading the platform (without changing anything else) will change the command invocation for end-users.</p>
+<p>As an example, the following on Platform API version 0.9:</p>
+<pre tabindex="0"><code>docker run --entrypoint from-newer-buildpack my-image user-1 user-2
+</code></pre><p>will result in the following command invocation: <code>some-command always-1 always-2 override-1 override-2 user-1 user-2</code>, where overridable arguments are treated like regular arguments, and user-provided arguments are always appended. Upgrading the platform will cause <code>override-1</code> and <code>override-2</code> to be dropped, as shown above.</p>
 <h4 id="older-buildpacks">Older buildpacks</h4>
 <p>Process types contributed by older buildpacks (Buildpack API 0.8 and below) do not have overridable process arguments. Looking at metadata.toml:</p>
 <pre tabindex="0"><code>[[processes]]
 type = &#34;from-older-buildpack&#34;
 command = [&#34;some-command&#34;]
 args = [&#34;always-1&#34;, &#34;always-2&#34;]
 </code></pre><p>The <code>command</code> list will never have more than one element. <code>always-1</code> and <code>always-2</code> are arguments that are always provided to <code>some-command</code>. If no user-provided arguments are specified when the application image is launched, <code>always-1</code> and <code>always-2</code> will be provided only. If user-provided arguments are specified, these will be <strong>appended</strong> to the <code>args</code> list. Example:</p>
-<pre tabindex="0"><code>docker run --entrypoint from-newer-buildpack my-image
+<pre tabindex="0"><code>docker run --entrypoint from-older-buildpack my-image
 </code></pre><p>will result in the following command invocation: <code>some-command always-1 always-2</code>. However:</p>
 <pre tabindex="0"><code>docker run --entrypoint from-older-buildpack my-image user-1 user-2
 </code></pre><p>will result in the following command invocation: <code>some-command always-1 always-2 user-1 user-2</code>.</p>
+<h4 id="implications-of-upgrading-1">Implications of upgrading</h4>
+<p>For processes from older buildpacks, upgrading the platform will not change the command invocation.</p>
 <h3 id="image-extensions-are-supported-experimental">Image extensions are supported (experimental)</h3>
 <p>Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see <a href="/docs/features/dockerfiles">here</a> for more information). Image extensions output Dockerfiles which are applied by the lifecycle using [kaniko][https://github.com/GoogleContainerTools/kaniko], a tool for building container images in Kubernetes, as a library.</p>
 <p>Note: image extensions are not supported for Windows container images.</p>

docs/tools/index.html

@@ -763,7 +763,7 @@ <h2><a href="https://buildpacks.io/docs/tools/gitlab/" class="">Gitlab Auto DevO
             </div>
 
           <h2><a href="https://buildpacks.io/docs/tools/kpack/" class="">kpack</a></h2>
-          <p class="m-1"><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform maintained by <a href="https://www.vmware.com/company.html">VMware</a> under the <a href="https://tanzu.vmware.com/build-service">VMware Tanzu project</a> that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
+          <p class="m-1"><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform, belonging to the <a href="https://github.com/buildpacks-community">Buildpacks Community</a> organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
 
 
             <div class="text-md-right">

docs/tools/index.xml

@@ -28,7 +28,7 @@ build applications prior to deploying them.&lt;/p&gt;</description>
       <link>https://buildpacks.io/docs/tools/kpack/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://buildpacks.io/docs/tools/kpack/</guid>
-      <description>&lt;p&gt;&lt;a href=&#34;https://github.com/pivotal/kpack&#34;&gt;kpack&lt;/a&gt; is a Kubernetes native platform maintained by &lt;a href=&#34;https://www.vmware.com/company.html&#34;&gt;VMware&lt;/a&gt; under the &lt;a href=&#34;https://tanzu.vmware.com/build-service&#34;&gt;VMware Tanzu project&lt;/a&gt; that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).&lt;/p&gt;</description>
+      <description>&lt;p&gt;&lt;a href=&#34;https://github.com/pivotal/kpack&#34;&gt;kpack&lt;/a&gt; is a Kubernetes native platform, belonging to the &lt;a href=&#34;https://github.com/buildpacks-community&#34;&gt;Buildpacks Community&lt;/a&gt; organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).&lt;/p&gt;</description>
     </item>
     <item>
       <title>Project &#34;Piper&#34;</title>

docs/tools/kpack/index.html

@@ -8,7 +8,7 @@
 <meta charset="utf-8">
 <meta http-equiv="x-ua-compatible" content="ie=edge">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
-<meta name="description" content="kpack is a Kubernetes native platform maintained by VMware under the VMware Tanzu project that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation…"/>
+<meta name="description" content="kpack is a Kubernetes native platform, belonging to the Buildpacks Community organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation…"/>
 <link rel="canonical" content="https://buildpacks.io/docs/tools/kpack/">
 <link rel="icon" type="image/png" href="/images/favicon.png">
 
@@ -22,7 +22,7 @@
 <meta property="og:url" content="https://buildpacks.io/docs/tools/kpack/">
 <meta property="og:locale" content="en_US">
 <meta property="og:site_name" content="Cloud Native Buildpacks">
-<meta property="og:description" content="kpack is a Kubernetes native platform maintained by VMware under the VMware Tanzu project that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation…">
+<meta property="og:description" content="kpack is a Kubernetes native platform, belonging to the Buildpacks Community organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation…">
 <meta property="og:type" content="article">
 <meta property="og:image" content="https://buildpacks.io/images/buildpacks-social-card.jpg">
 <meta property="og:image:alt" content="Buildpacks project logo">
@@ -738,7 +738,7 @@
           <h1 class="title">kpack</h1>
         </div>
 
-        <p><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform maintained by <a href="https://www.vmware.com/company.html">VMware</a> under the <a href="https://tanzu.vmware.com/build-service">VMware Tanzu project</a> that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
+        <p><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform, belonging to the <a href="https://github.com/buildpacks-community">Buildpacks Community</a> organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
 <h2 id="use">Use</h2>
 <p>To use <a href="https://github.com/pivotal/kpack">kpack</a> you can follow their <a href="https://github.com/pivotal/kpack/blob/master/docs/tutorial.md">tutorial</a> for details on how to create a builder and use it to create application images.
 An example <code>kpack Image</code> configuration looks like -</p>
@@ -763,6 +763,7 @@ <h3 id="references">References</h3>
 <li><a href="https://github.com/pivotal/kpack">kpack GitHub repository</a></li>
 <li><a href="https://github.com/vmware-tanzu/kpack-cli/blob/master/docs/kp.md">kpack CLI Github repository</a></li>
 <li><a href="https://github.com/pivotal/kpack/blob/master/docs/tutorial.md">kpack tutorial</a></li>
+<li>[kpack Donation announcement] <a href="https://medium.com/buildpacks/kpack-joins-the-buildpacks-community-organization-223e59bda951">announcement</a></li>
 </ul>
 
 

index.xml

@@ -593,7 +593,7 @@ build applications prior to deploying them.&lt;/p&gt;</description>
       <link>https://buildpacks.io/docs/tools/kpack/</link>
       <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
       <guid>https://buildpacks.io/docs/tools/kpack/</guid>
-      <description>&lt;p&gt;&lt;a href=&#34;https://github.com/pivotal/kpack&#34;&gt;kpack&lt;/a&gt; is a Kubernetes native platform maintained by &lt;a href=&#34;https://www.vmware.com/company.html&#34;&gt;VMware&lt;/a&gt; under the &lt;a href=&#34;https://tanzu.vmware.com/build-service&#34;&gt;VMware Tanzu project&lt;/a&gt; that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).&lt;/p&gt;</description>
+      <description>&lt;p&gt;&lt;a href=&#34;https://github.com/pivotal/kpack&#34;&gt;kpack&lt;/a&gt; is a Kubernetes native platform, belonging to the &lt;a href=&#34;https://github.com/buildpacks-community&#34;&gt;Buildpacks Community&lt;/a&gt; organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).&lt;/p&gt;</description>
     </item>
     <item>
       <title>pack</title>