<div dir="ltr">Hi Nathan,<div><br></div><div>>  The current model of forking seems like a nightmare.  One has to manually copy code changes from one repository to another.</div><div><br><div>You don't have to copy code manually in the current split-repo model. You can just add the other repos like JDK22 as a new remote to your base JDK, just like how you would work with the main repository and forks. The same can be done for other JDK projects.</div><div><br></div><div>That said, I support this move; having JDK stabilization in new branches instead of new repos is much cleaner; we don't need to watch extra new repositories for the stabilization that's part of the base JDK project and don't need to be concerned about repo spams.</div><div><br></div><div>Best,</div><div>Chen Liang</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2024 at 11:36 AM Nathan Reynolds <<a href="mailto:numeralnathan@gmail.com">numeralnathan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I don't work on the JDK so my "vote" doesn't carry any weight.</div><div><br></div><div>I've been using the Git branching model for various repositories for about 10 years now.  It has never failed me and has been very easy.</div><div><br></div><div>I do recommend the model where the main branch is for the next JDK (i.e., JDK 23).  When the release starts to wind down, create a jdk23 branch.  Fixes will merge into the jdk23 branch and this branch will merge into main.  Let's assume we've been doing this model since JDK 1.  If a fix needs to backport to jdk21, jdk17, and others, then we can simply cherry-pick the changes into private branches based on jdk21, jdk17, and others.<br></div><div><br></div><div></div><div>The current model of forking seems like a nightmare.  One has to manually copy code changes from one repository to another.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2024 at 9:22 AM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" target="_blank">kevin.rushforth@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 3/22/2024 9:12 AM, Magnus Ihse Bursie wrote:<br>
> On 2024-03-20 17:20, Iris Clark wrote:<br>
><br>
>> I propose that the JDK feature releases (e.g., JDK 23, JDK 24) use <br>
>> branches<br>
>> rather than repositories for stabilization.  The "master" branch will <br>
>> continue<br>
>> to be the always-open default branch, used for main-line <br>
>> development.  Instead<br>
>> of a stabilization repository "jdk$N" (where $N is the version number <br>
>> of the<br>
>> next release, e.g. "jdk23" or "jdk24"), we will use a stabilization <br>
>> branch<br>
>> with the same name, "jdk$N".  Changes will be backported from the master<br>
>> branch via pull requests targeting the release-specific stabilization <br>
>> branch.<br>
>> The stabilization branch will be locked when the release is delivered.<br>
>><br>
>> I suggest that we adopt this proposal for JDK 23 RDP 1, June 2024.<br>
>><br>
>> Concerns?<br>
><br>
> Since I have not seen much feedback, I'd like to emphasize my support <br>
> for this proposed change. The only concern I have is "What took us so <br>
> long?" (and yes, I understand why it took so long). :-) But maybe the <br>
> lack of feedback is just an indication that everyone agrees with this.<br>
><br>
> As with all changes, I anticipate some minor hiccups. Ideally, they <br>
> will all be resolved prior to the switch. However, that small risk <br>
> should not stop us from starting to use this, much saner, model.<br>
<br>
I also fully support this proposed change. We have been successfully <br>
using a branching model for stabilizing JavaFX feature releases in the <br>
jfx repo for about 4 years.<br>
<br>
-- Kevin<br>
<br>
</blockquote></div>
</blockquote></div>