Skip to content

3.x is now 3.10 with Resolver 2 like Maven 4#47

Open
hboutemy wants to merge 1 commit into
masterfrom
mvn-3.10
Open

3.x is now 3.10 with Resolver 2 like Maven 4#47
hboutemy wants to merge 1 commit into
masterfrom
mvn-3.10

Conversation

@hboutemy
Copy link
Copy Markdown
Member

No description provided.

@hboutemy hboutemy requested a review from cstamas May 27, 2026 21:20
@cstamas
Copy link
Copy Markdown
Member

cstamas commented May 27, 2026

LGTM, but one Q: why mvn-3.x vs mvn-3.9.x? Why not then mvn-3.9.x and mvn-3.10.x instead?
Also, what is the plan re 3.9.x? For how long it remains in here?

Copy link
Copy Markdown
Member

@cstamas cstamas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ok, but I locally -- as my personal preference -- try to consistently keep directories as major.minor, so 3.9.x and 3.10.x and 4.0.x etc

@hboutemy
Copy link
Copy Markdown
Member Author

in the past we had only one Maven core
then we had 2: 3 and 4, so we kept maven for master branch and 3.x for current 3 branch, with stable directory names on disk

now, we have 2 Maven 4 branches and 2 Maven 3 branches maintained in parallel: yes, this complexity requires to define a common approach to get same local directories for different people

in addition, we have the subtility of mvnd branches and resolver branches

yes, this is the right time to define a local directory approach that we'll keep, either trying to keep stable names even if Git branches names change or not...

for the past year, we did:

|-- core
|   |-- build-cache
|   |-- maven
|   |-- maven-4.0.x
|   |-- mvnd
|   |-- resolver
|   |-- resolver-ant-tasks
|   |-- wrapper
|   `-- 3.x
|       |-- its
|       |-- maven-3
|       |-- mvnd-1
|       `-- resolver-1

what would be the local directories proposal for the current approach done in Git?

@hboutemy
Copy link
Copy Markdown
Member Author

notice: aligning mvnd versions to embedded Maven versions would make it much easier to understand from a peanut gallery (instead of mapping mvnd 1.0 & 2.0 to Maven 3 and 4, and having random patch version from mvnd to minor+patch versions of Maven)

@hboutemy
Copy link
Copy Markdown
Member Author

hboutemy commented May 29, 2026

re-thinking at it:
the directory structure has been done to be stable: it works when we have 2 branches, like Maven 4 vs Maven 3 (with 2 directory names patterns: sometimes the detault remains for Maven 3 and we have a -4 directory, sometimes it is the opposite: Maven 4 is the default, and we have a -3)

With Maven core, we now have an additional topic: for each major, there are 2 maintenance branches:

  • for Maven 3, we have the current active that is now 3.10, and the "security only" that is 3.9: we until now ignored the "security only" branch in the directory structure
  • for Maven 4, we have 4.0 and 4.1, 2 really active development branches...

my proposal now that the analysis is done is:

  • for Maven 3, keep the stable directory name structure for the current branch (3.10 as of today) and continue ignore the security branch (3.9 as of today)
  • for Maven 4, let's keep this unusual maven + maven-4.0.x names: not ideal, but I hope this 4.0 vs 4.1 topic will be temporary...

which finally means that we should go to

|-- core
|   |-- build-cache
|   |-- maven
|   |-- maven-4.0.x
|   |-- mvnd
|   |-- resolver
|   |-- resolver-ant-tasks
|   |-- wrapper
|   `-- 3.x
|       |-- its
|       |-- maven-3
|       `-- mvnd-1

only resolver-1 has to be removed, given current Maven 3 (3.10) uses the default Resolver 2
and Maven 3.9 is ignored: we are working on 3.10 for Maven 3 (and when we were working on Maven 3.9, we did not have any structure for 3.8 security fixes, as they are very unusual)

thoughts?
before I update the PR content based on this logic

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants