What version label to use for a forked maven project?

问题

I often times have to fork a Java project that uses Maven (usually on github).

When I fork the project and make my changes I generally want to cut a release to my own private (but on the internet) maven repository.

Thus the question of what the version label should be for my custom release. I can't do SNAPSHOT as I need it to be a release. Sometimes I suffix the project with .ADAMGENT (cause I'm a narcissist). Lets say I fork 1.0.4-SNAPSHOT. I might change it to 1.0.4.ADAMGENT . I have no idea if that is a good idea. In some cases I can't even suffix it with .ADAMGENT as Spring's Gradle build tools don't like that. So for Spring projects I do .ADAMGENT.RELEASE or .ADAMGENT.M1 if its a milestone.

What do others do?

Update: although I said fork I ment more of a patch level change. The bounty (by a different user) on the other hand might be for fork and/or patch

回答1:

I usually add a suffix (e.g. name) and then a running number to avoid confusing multiple releases that I make based on the upstream version. In your setup, this would probably translate to the something like this:

1.0.4-ADAMGENT-1

which would then be followed by 1.0.4-ADAMGENT-2 in case you have to make another change.

Definitely keep the artifact and group ID from the original project and also the version you're basing your changes on, this will come in handy later, if you ever have to find out which version you've been working on. And it makes switching to the official version easier, if your changes are included upstream.

回答2:

Because you are forking, use a different group ID.

The reality is, that once you start making changes to your local fork, it is a different artifact. An artifact that is made by your organization, not the one you took it from.

With regard to version number, if your changes are always going to be minor, I'd use the major and possibly the minor version number of the source tree when I forked, otherwise, I'd start all over again at 1.0.0 and make a note in the project POM regarding what version I forked it from.

For example:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.adamgent</groupId>
    <artifactId>project-xyz</artifactId> <!-- same artifact ID -->
    <version>1.0.0-RELEASE</version>
    <name>My Project XYZ</name> <!-- different display name -->
    <description>My fork of project XYZ created from v5.42.0 of original sources.</description>
    ....

It isn't any more difficult to switch a group ID for a dependency than to switch a version ID. Both mechanisms can be used to easily get you the release artifact you want. However, by changing the group ID, you get the follow advantages:

1. you can more easily keep track of your forks within Nexus
2. you eliminate any confusion that might arise from having artifacts from an organization that they did not create
3. you stay within the standard guidelines for Maven version identifiers

回答3:

If it's a snapshot, I suggest to use the original revision number (is that possible with git?) or the date you forked it, with your ADAMGENT (adding your own suffix is a very good idea)

e.g.

1.0.4-2011-09-12.ADAMGENT

回答4:

I did come up with my own solution. I won't mark it correct as I think @DavidH does have some valid points and if Maven had the level of configuration that Ivy has of replacing groupid (and/or I figured out in sonatype how to do it) I probably would mark it correct. Otherwise I firmly believe a fork should be a different namespace and Java package names should be somewhat inline with your projects groupid. Also for my situation I often need to do this for a bug fix so its not a fork.

This is what I do and it is based on how maven reads version numbers and what Sonatype somewhat does:

First I setup my own public but non central repository where I will publish my version into. You can use github and/or googlecode to host such a repo. There are guides on the net on how to do this and how to publish to it so I won't go into that.

For version numbers I follow this format except for Spring because Spring's build system has strange requirements as noted in my question:

1.0.4-ADAMGENT-1

Some more changes and release:

1.0.4-ADAMGENT-2

You can see that Maven will mostly understand this format by looking at the code. The issue is the ADAMGENT qualifier. Maven only understand a few qualifiers "alpha", "beta", "milestone", "rc", "snapshot", "", "sp"` and "ga", "final", "cr" properly.

The ones it does not are lexical ordered (ADAMGENT in this case) which is fine and I suppose you could up the incremental version (4) if that is a problem.

来源：https://stackoverflow.com/questions/10415550/what-version-label-to-use-for-a-forked-maven-project