hmm how does that help between releases? You need to adress stable, labeled versions of artifacts .. so in my feeling you aren't allowed to use any snapshot version at all .. ?
Michael > I think (actually I hope) he's talking about between releases. > > trunk might be moving rapidly, so you fork a branch to work on a > feature... > you don't want the changes to the artifacts from trunk screwing with your > build until you are ready to merge the branch back to trunk... > > If he's got some other plan then I'd advise him against using timestamp > snapshots for such a crazy plan (which I'm sure he will share in an effort > to prove that it's not crazy) > > -Stephen > > 2009/4/22 David Hoffer <[email protected]> > >> 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]
