The most common misconception IMO is that a maven release == a release...

I consider a Release to an environment to be a well understood collection of 
tags of artifacts thats reproducible. An artifact should have an independent 
release cycle.

all you need to do is manage the deployables i.e. what exactly ends up in your 
war. You can do that in the pom for the war project. That way you have the 
power to go forwards and backwards or whatever in the actual war that gets 
deployed. The contents does not need to be linear over time.

On Thu, 13 Dec 2007 11:25:19 Eric Minick wrote:
> I'm looking at doing some releases using the maven release plugin. Our
> environment is a set of pretty typical in house development projects for
> some web-apps. So we have things like dev, qa and production
> environments for deployment and frequent releases.
>
> We don't want to cut a release before doing QA on it. So an ideal
> scenario is to put a snapshot build into QA, and get it approved. Once
> approved, we would want to release that code, verify that dependency
> changes didn't break things with regression tests, then move on to
> staging and production.
>
> A natural concern here is that there are likely more changes to the
> mainline code base that come in during testing and we would not want to
> release those. Getting the code that went into the tested build out of
> source control at release time is not a problem though.
>
> I have two questions:
>
> 1) Are there common \ recommended strategies for dealing with this type
> of scenerio?
> 2) If I just pull the old code out and run a release, is the SVN label
> (copy) command a local copy (which would only include the files in my
> release space) or a remote copy (which would include my newly checked in
> pom as well as any changes committed since we went to QA)?
>
> Thanks,
>
> Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to