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

[Chris Hegarty]

Hi,

Sorry for not replying earlier, but Magnus' email prompted me to do so.

Most projects that I work with operate this way - main/master as the tip 
for main-line development, and branches for stabilization/update lines 
of dev. I love the proposal, it is a step in the right direction and 
will help simplify my workflow.

While orthogonal, I would like to eventually see these version specific 
branches being used for the update release of the specific JDK version. 
I know that updates are handled somewhat separately, but maybe at some 
point in the future we could have it all in one repo! However, as I 
said, this is orthogonal and should not get in the way of this great 
proposal.

-Chris.

On 22/03/2024 16:12, 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.
> 
> /Magnus
>