You could do this: 1.0-SNAPSHOT 1.0-SNAPSHOT 1.0-SNAPSHOT 1.0-1 1.0-SNAPSHOT 1.0-SNAPSHOT 1.0-2 1.0-SNAPSHOT 1.0-3 1.0-SNAPSHOT 1.0-4
Note how after a release, you go back to 1.0-SNAPSHOT instead of 1.1-SNAPSHOT. I would only go to 1.1 once a branch for 1.0 has been established which would likely be made sometime between 1.0-1 to 1.0-4. We found this very valuable as anyone who has dependencies on us doesn't need to worry about changing version numbers all the time. They simply point to 1.0-SNAPSHOT and they get the latest. It also makes it easier for our testers since they always download the same version from Nexus. As I mentioned in my previous email, SNAPSHOT builds are displayed in the UI with the svn revision number embedded in the version. This should keep your testers happy since they will be testing against a precise version. It also lets you know on what svn revision a problem occurred. So in the above example, your final release is 1.0-4. This way, you don't have to respin the last build just to change the version and I believe everyone is happy. --- Todd Thiessen > -----Original Message----- > From: Arnaud X Dostes [mailto:[email protected]] > Sent: Tuesday, September 15, 2009 4:24 AM > To: Maven Users List > Subject: RE: How do you release your projects? > > Your deploy team is a bit annoying, it's just labeling, but > it seems that they have some weight, so let's leave that aside. > > This is a bad idea : > Well may be I can release "1.0" version all the time > and use the svn > revision as a buildnumber I display somewhere in the > app, but it sound > not very maven way to release "1.0" over and over. I > know that archiva > allow that, but I think that the .m2 repository won't > be updated. > > Because you're gonna overwrite the same release version over > and over, loosing history. > And yes, local repositories will not get updated unless > developers are told to delete the directory in question. > > There's pretty much 2 ways to conduct your acceptance review, > a/ either deliver a new snapshot of the same version (let's > say 1.0-SNAPSHOT over and over) and then the final package > will be 1.0 b/ deliver release versions with minor version > updates, 1.0, 1.1, 1.2, 1.3. 1.3 gets accepted, take > 1.4-SNAPSHOT (make sure there are no changes) and release it to 2.0 > > Or you can screw with their heads : > Use a <property></property> in your pom.xml with resource > filtering activated and when building the final package, pass > in a version number to be displayed in the 'about' box. > > You can also try to come to an agreement with your deploy > team on what version is going to be delivered to the client. > Let's say it's version 2.0, so you're gonna go 1.7,1.8,1.9, > 1.9.1, 1.9.2 etc... and when your acceptance phase is > validated, release 2.0 > > There's one last thing you can try : a sit down session with > them to get them to understand continuous integration. You > say tomato, they say tomato... > > Remember that you can set the release version to whatever you > want it to be when you release, so no need for the RC funny > business for the final deliverable, just ask them what they want. > > > > > Arnaud DOSTES > ' Direct Line : +41 22 744 18 85 | GDP : 639 18 85 | Email > : [email protected] > > -----Original Message----- > From: Julien Graglia [mailto:[email protected]] > Sent: Tuesday, September 15, 2009 9:59 AM > To: [email protected] > Subject: How do you release your projects? > > Hi, > > Release process A: > - the project is in 1.0-SNAPSHOT version > - near the end of the iteration, we start an "acceptance > review" (a long phase of testing). if it is ok a maven > release is done, if not corrections are made on the snapshot. > That release process is not good because the deploy team is > not very happy happy to "lose" the version they test and use > a fresh new release. > I know that it's only a re-packaging with new versions names > but they do not like it. > In fact, what they need is to do all their tests with one > version and use that version at the end. > So we change our release process to send maven release > "1.0-RC1", "1-0-RC2".. to the deploy team. So when everything > is ok they have a real released maven version. > > This is release process B : > - the project is in 1.0-SNAPSHOT version > - before the end of the iteration, we release a release > candidate named > 1.0-RC1 and we start 1.0-RC2-SNAPSHOT > - the acceptance tests are done on the 1.0-RC1. if > everything is ok, the deploy team can use that release and > the dev team can start 1.1-SNAPSHOT. > - if the acceptance tests failed, corrections are made > onto the 1.0-RC2-SNAPSHOT, then the 1.0-RC2 is released ...etc.... > > That's simple and easy, but we still have some problems with > that : the name of the version : they don't like "1.0-RC6" or > "1.0-RC2", they prefer to deliver version "1.0" to the client. > > Well may be I can release "1.0" version all the time and use > the svn revision as a buildnumber I display somewhere in the > app, but it sound not very maven way to release "1.0" over > and over. I know that archiva allow that, but I think that > the .m2 repository won't be updated. > > Do you facing the same kind of problems? > > -- > Julien Graglia > NetCeler > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of > securities, accuracy and completeness of information, viruses, > confidentiality, legal privilege, and legal entity disclaimers, > available at http://www.jpmorgan.com/pages/disclosures/email. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
