<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <br>

    <div class="moz-cite-prefix">On 3/21/2024 4:07 AM, Severin Gehwolf

      wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:7f95dd63bff94ca764d58226c2be464fe006f0e0.camel@redhat.com">

      <pre class="moz-quote-pre" wrap="">On Thu, 2024-03-21 at 11:42 +0100, Volker Simonis wrote:

</pre>

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">This proposal sounds interesting and reasonable.It would be especially

beneficial if the JDK Updates Project (added to CC) would adopt this

new model.

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">

We can consider it for jdk-updates at a later point. I don't think it's

good to conflate those two at this point. Lets get mainline JDK

development switched, first. See how it pans out for mainline and

corresponding downstream consumers.

Once we have that experience, we could model it for jdk-updates further

down the line.

</pre>

    </blockquote>

    <br>

    I agree. This proposal deliberately does not address update

    releases. Any changes to update releases would necessarily need a

    separate proposal with its own discussion. Waiting to see how it

    works in practice for the JDK Project seems wise.<br>

    <br>

    If and when the JDK Updates Project makes a proposal to switch to

    branches, the repository and branch structure -- specifically,

    whether to continue to have a per-release-family jdkNNu repo vs

    moving to a single jdk-updates repo -- would be a big part of that

    discussion. I have an opinion on that, based on experience with our

    internal update releases and with the GitHub workflow, but will

    leave it for that later discussion.<br>

    <br>

    -- Kevin<br>

    <br>

  </body>

</html>