(Back to JSTEP page)

Head branch renaming: 2.19/2.20->2.x, master->3.x

Author

Tatu Saloranta (@cowtowncoder)

Version history

• 2025-04-04: Create first proposal
• 2025-04-08: Update (master -> 3.x conversion completed)
• 2025-04-24: Update (2.20 -> 2.x conversion mostly completed)

Status

Almost complete as 2025-04-24, with 2.x branch creation after 2.19.0 release.

Branches before proposed changes

Currently we have 2 head branches:

• One dynamically changed branch for developing the next 2.x version of Jackson: currently this is 2.19
• master for developing upcoming Jackson 3.0 version

Of these, former (2.19) is selected as the "default branch" of repositories.

When we get to the first official 3.0 release, 3.0.0, we need to change branching somehow.

One possibility would be to just continue using master for the next 3.x version and branch off maintenance branches (3.0, 3.1, ...) similar to how 2.x maintenance branches are done.

But there is one issue with the way 2.x branches are handled:

• Every time we release the next 2.x version, we need to change default branch of every Jackson repo (to point to the new "head" branch)

The same problem would apply to new 3.x branches; but there is one further complication:

• There is just one "default" branch

This is problematic for our "Cascading re-build" CI job which we will trigger separately for 2.x and 3.x: while currently this works with combination of:

1. 2.x builds rely on "default" branch (and do not specify target branch)
2. 3.0-pre-release builds rely on static branch name of "master"

this system will not work once the head of 3.x does not have static name -- we would now need to modify every Cascading Rebuild job definition when new 3.x minor release is made.

Proposal: new 2.x and 3.x head branches

To resolve above-mentioned issues, here is a simple proposal:

1. Create new 2.x branch as the head branch for 2.x development
2. Rename master as 3.x to be the head branch for 3.x development
3. We can decide which of above should be the "default branch": possibly 2.x on very short term, then switch to 3.x (maybe as soon as when 3.0.0 is released)

Of these, we could rename master as 3.x at any time we want to.

Creation of 2.x probably makes most sense once 2.19.0 is released: this way we can avoid actual renaming and simple create new branch from 2.19 and switch over (2.x then being used to develop 2.20 first, then 2.21 etc).

Additional work beyond branch creation/re-naming consists of:

• Changing Github Actions/Workflows in places where existing branch names are used (or default relied on).
  • specifically, Cascading Rebuild jobs dep_build_v2.yml, dep_build_v3.yml and trigger_dep_builds_v2.yml, trigger_dep_builds_v3.yml need to be updated
  • Main CI job, main.yml, also needs to have 2.x / 3.x added as triggering branches

Suggested timeline

• We will rename master as 3.x immediately, modify Github workflows appropriately
• We will wait until 2.19.0 release before creating new 2.x branch, modify GH workflows at that point.

Current Status: completed

"2.19" -> "2.x" renaming/creation

Was completed on 2025-04-24.

"master" -> "3.x" renaming

Was completed on 2025-04-08.