For a larger audience, like a QA group, yes for sure I would recommend going with releases. Of course this is typically done as you get close to release.
If you are talking about very early testing of a release, then I think SNAPSHOTs are appropriate. But I don't see this as very different than the old way of building with ant. You would have to cut a concrete release with a certain release number for QA to pick up. If a bug was found, you would have to fix that bug and also increment the version number so QA would know to pick up the new version to test. I suppose the difference is that with Maven the versioning in done right within the pom. But with tools like the release plugin the versioning should, for the most part, be automatic. --- Todd Thiessen > -----Original Message----- > From: slanted [mailto:[email protected]] > Sent: Tuesday, November 10, 2009 1:57 PM > To: [email protected] > Subject: Re: development methodology > > > To Todd Thiessen > > I would say worry about versions at the same point in your > maven builds as you did in your old ant builds. You don't > need to be constantly cutting a new Maven release during your > development cycle. Stay with SNAPSHOTs until you get closer > to release. > > Thanks for the reply Todd. > > How would this work? If we decide to release a snapshot > version to QA and it turns out to be bug free - we would then > need to do another build as a release. Then the QA group > would naturally insist on regression testing the build all > over again. > > -Eric > > > > > slanted wrote: > > > > Our development team recently mavenized a couple of our web > applications. > > We are struggling a bit with the new development methodology. > > > > A brief description of our artifacts and our setup: > > > > We have 2 web applications: shop & signup. > > These 2 web applications are both dependant on 2 jars: > content.jar & > > libs.jar. > > We use IntelliJ for our IDE and Hudson for a CI/build server. > > > > Now for our 'process': > > > > - Suppose we add some new functionality to our libs.jar. > We increment the > > version, let's say from 1.0.0 to 1.0.1. > > - Now we release libs version 1.0.1 > > - Now we update the shop & signup web apps to be > dependant on libs 1.0.1. > > And we release both of them > > - Now QA finds a bug in the libs. > > - Change the libs.jar pom to be 1.0-SNAPSHOT, indicating > development. > > - The developers change shop & signup poms to be dependant on libs > > 1.0-SNAPSHOT > > - Develop the fix > > - Now we increment libs.jar to version 1.0.2 > > - Update shop & signup web apps to be dependant on 1.0.2. Release. > > - Another bug is found... > > - Change the libs.jar pom to be 1.0-SNAPSHOT, indicating > development > > - The developers change shop & signup poms to be dependant on libs > > 1.0-SNAPSHOT > > - Develop the fix... > > - And so on > > > > Now for the question: For a simple setup like this, is > Maven overkill? > > > > Our development process was quite a bit simpler when we > were using ANT > > and didn't worry about the versions. > > > > Before, everyone just updated from subversion and got the > latest code > > and there was no worrying about updating our pom files with each > > test/release cycle. > > > > We've gone the maven route and would like to stick with it. > > Could anyone comment on our process and maybe point out > some ways to > > improve this constant pom updating? > > > > Thanks, > > Eric > > > > > > -- > View this message in context: > http://old.nabble.com/development-methodology-tp26287355p26287828.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
