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.
