somethign that occurrs to me... Take a step back and look at your processes... what determines when a build goes to QA? Look for a way to have that trigger a "mvn release" which will push the build to your release repo
On Thu, Oct 7, 2010 at 10:26 AM, Phillip Hellewell <[email protected]> wrote: > On Thu, Oct 7, 2010 at 11:08 AM, Thiessen, Todd (Todd) > <[email protected]> wrote: > >> So this is one aspect where our setup will differ slightly. We don't > >> need the release plugin to create tags for us because our build > >> scripts on our build machines are already set up to create tags with > >> every single build (even snapshots builds). > > > > I think we may be getting to crux of your. > > Yeah, I think we are getting closer... > > > SNAPSHOTS are never tagged. I think most would consider this a bad maven > practice. This isn't what a SNAPSHOT is for. A SNAPSHOT is meant to reflect > the source in your trunk, not a tag. > > > > If you wish to create a tag of something, create that build as a release. > You get around that, and I think all will be well for you. > > I don't think the existence or not of tags in SVN is a problem > exactly, but rather the crux of the problem is what do I do with all > these builds created by our build machines continuously? Some of them > will end up going to QA; many of them won't. And we don't know > beforehand. So if I make them snapshot builds, I end up later wanting > the ability to copy them from the snapshot to the release repo, which > unfortunately I have found out is not trivial. But if I make them > release builds, then I have a whole lot of builds in the release repo, > many of which never even went to QA, hard to clean up, and there is no > way to see in the <dependency> sections of the poms whether they are > depending on QA approved builds or not. > > So is my problem becoming more clear now? What's the best solution for > this? > > Phillip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
