Home/ Questions/Q 5935811
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T15:18:30+00:00

To clarify the question : I am looking for established best-practices or a pro/con

  • 0

To clarify the question :

  • I am looking for established best-practices or a pro/con analysis of known practices
  • by project lifecycle I mean : deploy to pre-integration, integration, QA, preprod and prod environment.

For some context:
Our project deploys to integration and QA every week, currenlty we create a new release for each integration deployment, but this doesn’t feel right. It leads to updating all the poms every week breaking dev level dependencies, forcing every dev to do a refresh of their eclipse configurations. We have large workspaces and eclipse doesn’t handle the refreshes so well thus a lot of wasted time.

I am not overly familiar with the maven release conventions and have been unable to find the ones regarding the point of the application lifecycle when mvn release should be used.

If the pattern we use now is accepted/correct/established I will have another question 🙂

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The approach I use to avoid the Eclipse dev level dependency update issue is to leave the relevant trunk or branch version number unchanged until such time as the release becomes significant. This way you can have properly tagged/versioned releases to QA etc so that you can track issues back but not require devs to update dependencies. To achieve this I use the following command but override the version numbers to get the desired release number but re-enter the current snapshot version as the new snapshot version:

    mvn release:prepare -DautoVersionSubmodules=true

    P.S. I have a diagram that demonstrates this but unfortunately insufficient rights in this forum to attach it. I would happily provide it if someone can facilitate attaching.

    P.P.S Maybe now…

    enter image description here

    Note also the support for early branching (2.1) and late branching (2.2).

    • 0