Sorry, I might not be clear on the big problem you are trying to solve. The release plugin works for us. Its used for each dependency you need to release. We try to limit snapshot usage overall, that's just for things a project is actively changing, else use a released version.
The 'biggest' problem, I have had, is not being able to use version ranges...means I have to modify the dependency version in the consuming projects, but never more than one per per dependency so its manageable. Now I see there is the versions-maven-plugin so potentially this will allow version ranges which will eliminate this manual process. -Dave On Wed, Apr 22, 2009 at 11:17 AM, Michael Hüttermann < [email protected]> wrote: > starting at lowest dependencies and work the way ... having a pretty big > build system this sounds like a nightmare. Just only using the maven > release plugin on the top level isn't enough right ?! > > Michael > > > > > We use snapshot for all versions while developing then when release time > > comes we release (maven release plugin) each project, starting at the > > lowest > > dependency and work our way up to the top. The release plugin will > > automatically update each project to the next snapshot version, as well > as > > SCM tagging, etc. > > > > > > On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann < > > [email protected]> wrote: > > > >> ok, I see, thanks! There is another concept using a generic version: > >> snapshots. What do you do with your SNAPSHOTs while branching then? Do > >> you > >> go through all your POMs and dependencies replacing the snapshot token > >> with the real snapshot version including timestamp? You can say "ok, I > >> will never use RELEASE" but you want to use the snapshot mechanism in > >> the > >> daily work for sure I guess. What's your strategy here while branching ? > >> > >> Thanks for your time !!! > >> > >> Michael > >> > >> > >> > >> > 2009/4/22 Michael Hüttermann <[email protected]> > >> > > >> >> Hello experts, > >> >> > >> >> how do you set up the process if you use RELEASE for a dependency in > >> a > >> >> POM, and work with VCS branches ? > >> > > >> > > >> > you stop using RELEASE for a dependency. > >> > > >> > RELEASE corresponds to the last released version... so if you release, > >> in > >> > order > >> > > >> > 1.0.0 > >> > 1.0.1 > >> > 1.1.0 > >> > 1.1.1 > >> > 2.0.0 > >> > 1.0.2 > >> > > >> > Then RELEASE will correspond to 1.0.2 as that was the last version > >> > released. > >> > > >> > The solution is to use version ranges, i.e. work on the 1.0.x branch > >> would > >> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > >> > 1.0.0 > >> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means > >> > that > >> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is > >> less > >> > than 1.1.0) > >> > > >> > Of course version ranges only work if you follow maven's rules for > >> version > >> > numbering... if you cannot follow maven's (some would say slightly > >> > strange) > >> > version numbering scheme you will need to do some manual work... to > >> help > >> > automate the manual work, you'll probably end up using > >> > versions-maven-plugin > >> > and specifying the version using a property. > >> > > >> > > >> >> What is your best practice? Probably a > >> >> branch will have to adress another, older version of an artifact, > >> >> actually > >> >> it has to adress a stable, tagged version. What happens if on HEAD > >> you > >> >> use > >> >> new versions of dependencies (so a new version for RELEASE), ... do > >> you > >> >> adjust all of your branches to remove the RELEASE token and enter a > >> >> dedicated version? Isn't that a nightmare ? > >> > > >> > > >> > I think you will realise from my earlier comment that there is *no way > >> in > >> > hell* that you would use RELEASE. > >> > > >> > FYI, the LATEST and RELEASE versions were initially more for use in > >> > specifying plugin versions... but they are so problematic that > >> everyone > >> > pretty much avoids them > >> > > >> > -Stephen > >> > > >> >> > >> >> > >> >> Thanks !! > >> >> > >> >> > >> >> Michael > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
