Yes, this is a typical, almost specific CVS problem that's understandable. As the versioning is done at the file level, and not at the repo one, it can be necessary to tag to be able to identify the code corresponding to a snapshot (even if, imo, if you're depending on a snapshot revision, and try debugging a snapshot version that's not the dev version, you have a problem in your dev process).
This problem doesn't exist with SVN. For example, we use the buildnumber-maven-plugin and add the svn repository revision number to the manifest for each build. So finding corresponding code for a jar is no problem at all for us, but we actually hardly need it. For the dev process, only in my opinion, I think automatically releasing every nights isn't a very good pratice. I rather think the release process should be actually 100% standalone, but *manually* initiated (giving the new version and so). Cheers 2010/9/15 Bengt Rodehav <[email protected]> > We've had similar questions where I work. The question has been related to > how and when to create tags in CVS (preferrably using the > maven-release-plugin). > > Some people advocate tagging every build so that it can be recreated in > case > it was fit for delivery. This is a problem when using CVS since huge number > of tags are not handled very well. > > However, builds that could potentially become a released version must be > recreatable somehow which implies a tag in the version control system. > Whenever a "release candidate" is built, doesn't it have to be tagged - and > therefore released? > > When we enter a system testing period close to the release of a new > version. > We normally build and deploy new versions automatically every day. At some > point we decide that it's good enough to release. It is then imperative > that > the latest build (which we have used for testing) is the one we package and > tag. > > What are the best practices around this? I'm very curious to know how other > organisations handle this using maven. > > /Bengt > > > 2010/9/15 Baptiste MATHUS <[email protected]> > > > Well, for example, we don't release automatically. We launch manually it > > via a special release plugin through hudson, itself launching a maven > > release through the maven-release-plugin. > > > > This makes it easier to keep a clean release environment. Releasing from > a > > development machine would add risk since it (1) might be less close to > the > > production system and (2) might contain things depending on the dev box > > that > > wasn't added to the SCM. > > > > Snapshot builds are totally sufficient for us to handle testing purposes. > > > > Cheers > > > > 2010/9/15 baz themail <[email protected]> > > > > > Hi, > > > > > > I have been searching the maven website and articles but not sure if i > > > get the best practice for managing snapshots and release. > > > Specifically, if continuous builds produce maven snapshot builds, then > > > when will i produce maven release builds using maven release plug-in? > > > > > > Will I ever produce a maven release build via an automated build job > > > that runs daily for example? The problem with that is: Because maven > > > plugin is incrementing pom.xml, and the automated build job will > > > always detect changes even tho there is no changes in the produce > > > software code. Does it even make sense? Or, release build should be > > > run manually depending on the release schedule? > > > > > > Thank you. > > > > > > A. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
