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

[Nathan Reynolds]

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/82df162a/attachment.htm>