JDK-8232434 : Decide on jfx repo branching model
  • Type: Task
  • Component: javafx
  • Sub-Component: other
  • Affected Version: openjfx11,openjfx13,openjfx14
  • Priority: P2
  • Status: Resolved
  • Resolution: Delivered
  • Submitted: 2019-10-16
  • Updated: 2020-01-11
  • Resolved: 2020-01-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
openjfx14Resolved
Related Reports
Relates :  
JDK-8231325 - ��� Switch official FX mainline repo to GitHub using Skara tooling
Description
As a follow-on to moving the jfx repo to git, we need to decide on our branching model.

Here are some high-level thoughts:
- we probably want to use branches in main repo for stabilization of feature releases
- it might or might not be a good idea to have branches in the main repo for update releases (note that it is possible to have different maintainers / policies / etc)
- in any case, we need to adopt a consistent naming policy for branches: to match jdk, no "-" between jfx and NN, e.g., jfx13 not jfx-13
Comments
Johan and I discussed this offline, and propose to go with proposal #2. The details are as follows: We will use a single "jfx" repo for all code lines going forward (we could also bring jfx13 into the mix if we wanted to do so). The master branch will always be the latest development line: e.g., it is 14 as of today and will transition to be 15 at RDP1 of JavaFX 14 (Thursday, Jan 9 at 23:59 Pacific). A new "jfxNN" branch will be created at RDP1 of each release. So for example, I will create a "jfx14" branch early Friday morning my time with the branch point being the content as of the RDP1 date/time. Once this happens, all tagging and building for 14 needs to happen on the "jfx14" branch. After the fork, all PRs for fixes that are intended for 14 will need to be targeted to the jfx14 branch. jfx [repo] master [branch] -- development code line, PRs are targeted here by default jfx14 [branch] -- created at RDP1 of JavaFX 14; PRs for 14 would be targeted to this branch up to JavaFX 14 GA and then it would be used for update releases (14.0.1, etc). jfx15 [branch] -- created at RDP1 of JavaFX 15; PRs for 15 would be targeted to this branch up to JavaFX 15 GA and then it would be used for update releases (15.0.1, etc). ... There is still an open question as to whether we need separate branches for update releases (e.g., branches for jfx14.0.1, jfx14.0.2). My thought is that this would only be needed if there are enough fixes going in that it makes sense to fork it early so development can continue for the next update release. Currently this is not the case, so it seems unneeded, but we can revisit this at any time. If we do decide that a branch is needed for an update release, such branches could be permanent or temporary. In case we decide on a permanent branch scheme, we would need to create them consistently for all dot-dot releases once we decide to start doing this; they would be made read-only after that release. In case we decide on a temporary branch scheme, we would create a jfxNN.0.M release only when needed and would delete it after the release. In all cases, each release will be tagged so there will never be a problem finding the sources for any release.
11-01-2020
Here are the two main alternatives we are considering. Proposal #1 1. In mainline jfx repo, use jfxNN branches for stabilizing feature releases: e.g., jfx14, jfx15, etc. -- consider importing jfx13 branch from jfx13 repo (and making it read-only) 2. Create a separate jfxNNu repo for update releases: e.g., jfx13u, jfx14u -- rename jfx13 repo to jfx13u 3. In jfxNNu repo, use jfxNN.0.M branches for stabilizing the releases: example: jfx13.0.1, jfx13.0.2 -- alternatively, if we never have overlapping releases, the NN.0.M release can be done from the master branch. Proposal #2 Rather than separate update release repos, continue to use jfx13, jfx14, etc., for update releases: 1. In mainline jfx repo, use jfxNN branches for stabilizing feature releases: e.g., jfx14, jfx15, etc. -- Import jfx13 branch from jfx13 repo 2. After GA, use the jfxNN branch for update releases 3. Fork jfxNN.0.M branches for stabilizing the releases: example: jfx13.0.1, jfx13.0.2 -- alternatively, if we never have overlapping releases, the NN.0.M release can be done from the jfxNN branch.
06-01-2020