Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Given module "shared", "A" and "B" where A and B depend upon a SNAPSHOT version of "shared":

While releasing "A", we need to release a new version of "shared". Let's call this version shared-1.0.3. Thus, shared is currently in version 1.0.3-SNAPSHOT. After 1.0.3 is released, the latest version of shared on the trunk is 1.0.4-SNAPSHOT. However, the developers of "A" who needed the new version of shared may be unaware of "B" and any other projects, so they will probably forget to change B's dependency on shared from shared-1.0.3-SNAPSHOT to shared-1.0.4-SNAPSHOT.

How do I best manage this situation?

Tool assistance

There might be a tool that could help with this problem by finding all the other modules that depend on "shared" and update their poms. This causes a bit of "noise" in the revision control system, and the tool might also miss places.

Release more detailed versions. Dual version in POM?

The reason we want to release 1.0.3, 1.0.4, 1.0.5 etc is that we are not making major structural changes to the code. We just need to make a release of what's there at a particular point in time. If we set the version to 1.0-SNAPSHOT and ask the release plugin to keep the version number, but add an incremented patchlevel, this would work perfectly.

So we would have 1.0-SNAPSHOT producing 1.0.3, 1.0.4, but the trunk version would keep 1.0-SNAPSHOT as its real version.

There are a few problems with this approach:

  • 1.0-SNAPSHOT means "version leading up to 1.0 (= 1.0.0)". It would probably be conceptually wrong to release 1.0.3 from here
  • How do we keep track of what the next version number is supposed to be? I would like to have this information be in the POM (and be updated by the release plugin), but it needs to be in addition to the SNAPSHOT version number.

Any tips? How do others deal with this?

  • No labels