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

[Volker Simonis]

Hi Iris,

This proposal sounds interesting and reasonable.It would be especially
beneficial if the JDK Updates Project (added to CC) would adopt this
new model. I think what you mention with "Stabilization branches have
been used successfully
by the JDK Updates Project since April 2021 (for 16.0.1)" only applies
to the first two updates of every feature release which are managed by
Oracle. As far as I can see, the community-maintained update trains
all do not use branches but instead *two* repositories ("jdkXXu" and
"jdkXXu-dev"). I think we could save quite some local disc space if
*all* update projects would be just branches in a single jdk-updates
repository.

One thing I can't overlook and where I'd like to get feedback from the
experts is how such a change will affect the JBS integration and the
GitHub privileges. Regarding JBS, will it still be possible to track
all the different update releases if they are managed as branches and
will this a large change? Regarding the GitHub privileges, will such a
change have any impact on how update maintainers can push to the
updates repositories/branches and how contributors will downport and
integrate backports?

Thank you and best regards,
Volker

On Wed, Mar 20, 2024 at 7:07 PM Iris Clark <iris.clark at oracle.com> wrote:
>
> Hi.
>
> The source code for JDK main-line development has been managed in git since
> September 2020 [0].
>
> The jdk repository is always open for commits.  In June and December, we fork
> the main line into a stabilization repository [1].  Changes are backported
> from the jdk repository into the stabilization repository, typically by the
> Committer who contributed the change [2].  The stabilization repository is
> archived when the release is delivered.
>
> We inherited the convention of forking repositories from Mercurial, which
> originally had weak support for branches.  Forking repositories entails some
> disadvantages.  Most notably, setting up a local branch tracking the "master"
> branch in a stabilization repository is cumbersome, which makes diffs across
> branches less convenient. Stabilization branches have been used successfully
> by the JDK Updates Project since April 2021 (for 16.0.1).
>
> 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?
>
> Thanks,
> Iris
>
> [0] https://mail.openjdk.org/pipermail/jdk-dev/2020-September/004694.html
> [1] https://openjdk.org/jeps/3#rdp-1
> [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-April/007612.html