> 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.
