maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiessen, Todd (Todd)" <>
Subject RE: Can't specify distributionManagement in settings.xml
Date Thu, 07 Oct 2010 17:33:01 GMT
> Why would the package change?  Were' using the assembly plugin to
> create a zip of the binaries (dlls, libs, and headers).  Why should
> that change if the code it's built from hasn't changed?

The names of the artifacts would change. The meta data used to retrieve the artifacts is also
different. Its just the way maven works.
> Actually, this is the first time I think I have heard someone
> specifically mention not giving SNAPSHOTs to QA.

Depends on what you mean by QA. I am using the term rather loosely here.

In our organization, we have different "levels" of QA. For each interation during development
we will actually do QA on SNAPSHOT builds.

But for builds that are a candidate release, these are built and tested as releases. These
are the builds that would go to an a larger scale QA. Could be an internal team within your
org or perhaps even an alpha trial site. This will vary depending on your org.

So you are right no one said you can't do any QA on a SNAPSHOT build. And to make my point
clear, I am only saying you only do your RELEASE QA on a RELEASED build. What you define as
"release QA" will of course vary but I think it is reasonable to say that you do it when you
get close to a release candidate build.

> Ok, I think you are on to something, but I still have a problem.  The
> root of my problem is that our build machines will be creating a lot
> of builds all the time, maybe even automatically every time a piece of
> code is checked in.

Yes. This is the root of your problems ;-). The solution I think is fairly simple though.
You would need to have two build plans on you CI machine. The primary one would be a SNAPSHOT
build that would fire off of every commit. NO TAG would be created as part of this build.
Do your early QA testing on these SNAPSHOT builds.

Then have a second plan you could fire manually as you approach release. This build would
be deployed to your release repository and of course have a tag. Tell your QA team to switch
to the released version of your product for testing.

View raw message