You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Julien Graglia <jg...@netceler.com> on 2009/09/15 09:58:33 UTC
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How do you release your projects?
Posted by Antonio Petrelli <an...@gmail.com>.
2009/9/15 Julien Graglia <jg...@netceler.com>:
> 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.
You may think to separate the "quality" of the software you release
from the "version number".
For instance, at Tiles we use x.y.z version numbers when we do the
release process. After the release, we decide what is the quality, and
disclaim it in the website and in announcements.
For instance:
Tiles 2.0.0 was a test build (not released).
Tiles 2.0.1 was a test build
Tiles 2.0.2 was Alpha quality.
Tiles 2.0.3 was Alpha quality.
Tiles 2.0.4 was Beta quality
Tiles 2.0.5 was GA quality
HTH
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How do you release your projects?
Posted by Todd Thiessen <th...@nortel.com>.
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:arnaud.x.dostes@jpmorgan.com]
> 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
> : arnaud.x.dostes@jpmorgan.com
>
> -----Original Message-----
> From: Julien Graglia [mailto:jgraglia@netceler.com]
> Sent: Tuesday, September 15, 2009 9:59 AM
> To: users@maven.apache.org
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How do you release your projects?
Posted by Todd Thiessen <th...@nortel.com>.
If your using svn, simply embed the svn revision in the version you
display.
So instead of 1.0-RC1, you can use 1.0-SNAPSHOT-xxx where xxx is the svn
revision number of the build. This should keep your testing team happy
as they would see a hard version number and it could help you as well
when issues are reported.
---
Todd Thiessen
> -----Original Message-----
> From: Arnaud X Dostes [mailto:arnaud.x.dostes@jpmorgan.com]
> 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
> : arnaud.x.dostes@jpmorgan.com
>
> -----Original Message-----
> From: Julien Graglia [mailto:jgraglia@netceler.com]
> Sent: Tuesday, September 15, 2009 9:59 AM
> To: users@maven.apache.org
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How do you release your projects?
Posted by Arnaud X Dostes <ar...@jpmorgan.com>.
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 : arnaud.x.dostes@jpmorgan.com
-----Original Message-----
From: Julien Graglia [mailto:jgraglia@netceler.com]
Sent: Tuesday, September 15, 2009 9:59 AM
To: users@maven.apache.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
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.
Re: How do you release your projects?
Posted by Antonio Petrelli <an...@gmail.com>.
2009/9/15 Julien Graglia <jg...@netceler.com>:
> - 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.
BTW, I forgot to say that, when changing the minor version number, we
branch the original trunk and let the trunk advance in the minor
version number.
For instance, we branched from trunk to maintain Tiles 2.0.x and
continue developing Tiles 2.1.x on the trunk.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org