Proposal: Branch github.com/openjdk/jdk for stabilization (instead of fork)

[-]

Hi Nathan,

>  The current model of forking seems like a nightmare.  One has to
manually copy code changes from one repository to another.

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.

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.

Best,
Chen Liang

On Fri, Mar 22, 2024 at 11:36 AM Nathan Reynolds <numeralnathan at gmail.com>
wrote:

> I don't work on the JDK so my "vote" doesn't carry any weight.
>
> 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.
>
> 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.
>
> The current model of forking seems like a nightmare.  One has to manually
> copy code changes from one repository to another.
>
> On Fri, Mar 22, 2024 at 9:22 AM Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>>
>>
>> On 3/22/2024 9:12 AM, Magnus Ihse Bursie wrote:
>> > On 2024-03-20 17:20, Iris Clark wrote:
>> >
>> >> I propose that the JDK feature releases (e.g., JDK 23, JDK 24) use
>> >> branches
>> >> rather than repositories for stabilization.  The "master" branch will
>> >> continue
>> >> to be the always-open default branch, used for main-line
>> >> development.  Instead
>> >> of a stabilization repository "jdk$N" (where $N is the version number
>> >> of the
>> >> next release, e.g. "jdk23" or "jdk24"), we will use a stabilization
>> >> branch
>> >> with the same name, "jdk$N".  Changes will be backported from the
>> master
>> >> branch via pull requests targeting the release-specific stabilization
>> >> branch.
>> >> The stabilization branch will be locked when the release is delivered.
>> >>
>> >> I suggest that we adopt this proposal for JDK 23 RDP 1, June 2024.
>> >>
>> >> Concerns?
>> >
>> > Since I have not seen much feedback, I'd like to emphasize my support
>> > for this proposed change. The only concern I have is "What took us so
>> > long?" (and yes, I understand why it took so long). :-) But maybe the
>> > lack of feedback is just an indication that everyone agrees with this.
>> >
>> > As with all changes, I anticipate some minor hiccups. Ideally, they
>> > will all be resolved prior to the switch. However, that small risk
>> > should not stop us from starting to use this, much saner, model.
>>
>> I also fully support this proposed change. We have been successfully
>> using a branching model for stabilizing JavaFX feature releases in the
>> jfx repo for about 4 years.
>>
>> -- Kevin
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20240322/82c86f11/attachment-0001.htm>