though if you are putting build numbers in a label and you plan on having more than 10 builds between minor version increments, left pad with zero's or else you will have to use crazy counting...
1 2 3 4 5 6 7 8 90 91 92 93 94 95 96 97 98 990 991 992 993 994 995 996 997 998 9990, etc On 3 April 2010 18:02, Stephen Connolly <[email protected]>wrote: > 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] >> >> >
