Skip to content

update Git branches for Maven-4 specific plugins and components #57

Open

Description

@hboutemy

we have a few plugins and components with a Maven 4 specific branch (either for Java Module support or anticipation of future Maven 4 API migration), while our current strategy is to maintain default for Maven 3, and switch to Maven 4 as default in the future, once users migration to Maven 4.0 has good progress

This is visible in the source tree:

...
|-- plugins
|   |-- core
          (default Maven 3)
|   |-- core-4
|   |   |-- maven-clean-plugin
|   |   |-- maven-compiler-plugin
|   |   |-- maven-deploy-plugin
|   |   |-- maven-install-plugin
|   |   `-- maven-resources-plugin
|   |-- packaging
          (default Maven 3)
|   |-- packaging-4
|   |   |-- maven-jar-plugin
|   |   `-- maven-source-plugin
|   |-- tools
          (default Maven 3)
|   `-- tools-4
|       `-- plugin-tools
...
|-- shared
      (default Maven 3)
|-- shared-4
|   |-- archiver
|   `-- filtering
...

From a Git perspective, though, this has been done by:

  • updating master default branch to Maven 4
  • creating a XXX-3.x branch for the Maven 3 branch

after discussion, the Git pattern is not consistent with our current approach (default for Maven 3, and Maven 4 specific when necessary)

for clarity, we need to switch the Git branches to match our intent:

  • rename master branch with Maven 4 specific code to XXX-4.x
  • rename XXX-3.x branch to master

on the few Git repositories:

Activity

  1. hboutemy commented on Sep 20, 2026

    @hboutemy
    MemberAuthor

    after deep dive into plugin-tools, master branch that currently builds 4.0.0-beta4-SNAPSHOT, is not a Maven 4 plugin: it remains a good old Maven 3 plugin, that perfectly works with Maven 3 and produces Maven 3 plugins
    it just has new features to be able to create a Maven 4 plugin descriptor, with its new fields additions (like afters) and using Maven 4 API annotation instead of plugin-tools ones

    => let's simply drop maven-plugin-tools-3.x branch, keep current master and just update it to build 3.17.0-SNAPSHOT

  2. self-assigned this
    on Sep 25, 2026
  3. slawekjaranowski commented on Sep 26, 2026

    @slawekjaranowski
    Member

    what will be default branch in Maven core project? as we have

    • master - 4.1
    • 4.0.x
    • 3.10.x
    • 3.9.x
  4. slawekjaranowski commented on Sep 26, 2026

    @slawekjaranowski
    Member

    I'm not sure what benefit we will have after such change, we will have the same branches to maintain

  5. desruisseaux commented on Sep 26, 2026

    @desruisseaux

    I agree with @slawekjaranowski. I'm not convinced that this renaming dance will not bring more confusion than what it aims to solve. The message that I would rather like to promote is that the master branches are the one where we would like peoples to put their effort, and the 3.x branches are in maintenance mode.

  6. slawekjaranowski commented on Sep 28, 2026

    @slawekjaranowski
    Member

    Next question what impact will be on current fork repo?

  7. slachiewicz commented on Oct 6, 2026

    @slachiewicz
  8. slachiewicz commented on Oct 6, 2026

    @slachiewicz
    Member

    For me option would be to rename some branches to drop project name prefix and keep only 3.x as name.
    Always we can set default branch to 3.x line without rename.

  9. ascheman commented on Oct 7, 2026

    @ascheman
    Contributor

    I'm also not convinced about this move.
    I think our efforts are to push for Maven 4 so after year or less, we will again need to swap main branch to v4?

    Perhaps it was not a good idea to spread feedback to too many places?

    I just see this comment here while the whole procedure is already on its way.

    If you generally object to the swap, would you mind to raise that in the dev@ mailing list (or perhaps find consensus within PMC first)?

  10. slawekjaranowski commented on Oct 7, 2026

    @slawekjaranowski
    Member

    I'm also miss discussion on dev@ list .....

  11. ascheman commented on Oct 7, 2026

    @ascheman
    Contributor

    I'm also miss discussion on dev@ list

    @slawekjaranowski there is one — I sent a [NOTICE] to dev@ on 6 Oct that explicitly asks for objections: https://lists.apache.org/thread/zg052t20fww3ghzhc9mqyh969c1661z5

    Let's consolidate the discussion there (as I suggested above), so the decision is made in one place. The pilot PR here is only to ground the mechanics — nothing is executed yet, and we won't proceed without consensus.

  12. 2 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions