There is nothing stopping you from rolling a release but keeping the next version number the same as the current
1.0-SNAPSHOT -> 1.0-build-56 -> 1.0-SNAPSHOT -> 1.0-build-57 -> 1.0-SNAPSHOT that way developers don't have to worry, QA get their named builds and everyone is happy (Might take two steps, but IIRC last time I used the release plugin you could have the old dev version = new dev version as long as the release version was non-SNAPSHOT) -STephen On 3 April 2010 17:59, Scott Susslin <[email protected]> wrote: > We're using Hudson to do our builds and Archiva to host our Maven remote > repo, which I'm quite happy with. > > The only resolution we can put on these version numbers is either once > every three weeks, or once a day. "Once every 3 weeks" versioning is already > happening; "once a day" is too much to saddle a person with (hence my > attempt to automate). > > BUT, not only does it look like it's not possible to do this, I can always > incorporate this build number into a display in the software, as opposed to > changing the artifact version. That should definitely suffice, and will keep > Archiva from getting overloaded with artifacts unnecessarily. > > Thanks everyone! I've been convinced to let it go. :-p > - Scott > > > > ----- Original Message ---- > From: "Gorham-Engard, Frank" <[email protected]> > To: Maven Users List <[email protected]> > Sent: Sat, April 3, 2010 7:26:39 AM > Subject: RE: Using variables in POM's version field > > Would I be right in thinking that the entire purpose of a SNAPSHOT artifact > is so that dependent modules don't have to be edited every time a new > artifact is produced. This makes the developer's job easier as long as they > are willing to accept the risk of having the dependee artifact change at any > time. > > If so, what would be reason for making an artifact with a build number in > the artifact version string that changes every time the artifact is deployed > and calling it a SNAPSHOT? The dependent developers would have to adjust > their dependencies each time a new dependee artifact is generated. But, that > is the way a release artifact works. Any advantage gained by deploying as a > SNAPSHOT is eliminated by having a different version string each time. > > Have I made it clear why doing this is misguided? Just go ahead and deploy > a release artifact with the build number in the version. The result is the > same. One artifact per version string. > > Also, the unresolved build number doesn't occur if you create the new build > number before starting Maven and pass it into the build as a property on the > command line. All build systems will support this need. I noticed everyone > has mentioned their favorite build system so I will mention mine, > QuickBuild2. A free version is available that will support a limited number > of projects. Includes a promotion model and configuration inheritance as > part of its design. No plugins needed. > > <!-- Frank Gorham-Engard → > "It is a misnomer to label any practice 'a best practice'; > a practice is only best in the specific context in which it performs > well." > > > -----Original Message----- > From: Kathryn Huxtable [mailto:[email protected]] > Sent: Friday, April 02, 2010 7:39 PM > To: Maven Users List > Subject: Re: Using variables in POM's version field > > Correct, and it's a bad idea. -K > > On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote: > > > I figured something like this was why it wasn't working. So sounds like, > given Maven 2, it can't work. True? > > > > > > > > ----- Original Message ---- > > From: Justin Edelson <[email protected]> > > To: Maven Users List <[email protected]> > > Sent: Fri, April 2, 2010 4:05:10 PM > > Subject: Re: Using variables in POM's version field > > > > Amongst other reasons, allowing runtime variable interpolation in the > > coordinates would prevent the reactor from properly calculating a > > multi-module build plan. The coordinates at the start of the build > > must remain the coordinates throughout the build. > > > > On Apr 2, 2010, at 5:14 PM, Scott Susslin <[email protected]> wrote: > > > >> Why? > >> > >> Also, is it possible? > >> > >> > >> > >> ----- Original Message ---- > >> From: Justin Edelson <[email protected]> > >> To: Maven Users List <[email protected]> > >> Sent: Fri, April 2, 2010 12:05:32 PM > >> Subject: Re: Using variables in POM's version field > >> > >> This is a bad idea. Don't do it. > >> > >> On Apr 2, 2010, at 2:21 PM, Scott Susslin <[email protected]> wrote: > >> > >>> I'm trying to use the buildnumber plugin to control the version > >>> field of a POM. > >>> > >>> <version>1.0.${buildNumber}-SNAPSHOT</version> > >>> > >>> The "package" phase works fine, creating a file with the parsed > >>> value in the filename. The "install" and "deploy" don't seem to > >>> parse the variable. When they run, I get something like the > >>> following: > >>> > >>> [INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/ > >>> repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/ > >>> artifact-0.1.${buildNumber}-SNAPSHOT.swc > >>> > >>> Anyone have any experience with this? > >>> > >>> Thanks > >>> - Scott > >>> > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
