I'm not sure that this it's specific to our process (If this is the
case, we should probably change it :) ).
I don't think that is possible to have always a clean trunk/branch.
Let me explain our process:
Each developer commit their changes on the trunk.
Each hour, continuum check for changes and package the components(and
execute the unit test).
Each night project is tagged (nightly tag) and the packages are
installed on a dev plateform and automatics tests are executed. This can
last 3 hours.
So, I agree with you that if a unit test fails, the developer have to
clean it (This shouldn't happen because tests should be executed before
commit). But the integration tests that last 3 hours can't be executed
on each commit, so something can be broken for several days because of a
regression. This also occurs at maven.
Additionaly, when performing (prepare) a release, It should be great to
be sure that the integration tests passed. So it can be useful to be
able to prepare/perform a release from a nightly tag.
Benoit
Kalle Korhonen wrote:
Ah ok, I see what you mean, but I think it's specific to your process. I'd
assume that most projects operate so they require that the trunk/branch
builds cleanly, rather than releasing from a specific time
point/version/label. In your case, it'd mean reverting the trunk to 04 feb,
then doing the release. In the meantime 05 feb would continue in branch or
with local copies only. I believe it's also common practice to require the
trunk builds to succeed. In our development process, we try not to prevent
build failures but to minimize the time the build remains in broken state,
with whatever means necessary (in some cases, reverting to previous state).
Kalle
On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote:
Image that we are working on the trunk. Every night a nightly snapshot
is created and deploy on a test servers and automatic tests are run
(they can last 4hours for a project).
on date 04 feb. every tests passed.
on date 05 feb. some tests are broken.
But on 06 feb we want to make a release (to install in prod). The dev
started on 05 feb are not finished, and so the nightly of 04 feb should
be released.
To do so, I suppose that release:prepare should be executed from the
nightly tag of 4 feb to remove all snapshots dependencies, tag the
release with an official tag, etc... The release prepare should create a
branch from this tag to do it ?
Benoit
Kalle Korhonen wrote:
I don't understand what you are asking. release:perform doesn't do
anything
else but runs deploy (and site-deploy) on the newly created tag; after
release:prepare, the release is already cut. If you want snapshots, why
don't you just deploy uniquely versioned snapshots nightly?
Kalle
On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote:
But I don't want to create an official version every night.
In the nightly version, there still have the -SNAPSHOT versions. So I
can't use release:perform to do it. I realy need to execute the
release:prepare from the nightly tag.
All projects here ask for this feature. I think this is a very good
feature to be able to release an "unofficial" version that is entirely
tested.
It seems strange that nobody has asked for this feature. All of you
always create a version from the last commits files of the trunk
(integration branch) ?
Is it possible to make an evolution of the release plugin to support
this
?
Benoit
Nicole Lacoste wrote:
Hi Benoit,
Yes I think so. Well I know you can release from a tag made with the
release prepare. The command is
mvn release:perform
-DconnectionUrl=scm:svn:file://your-url-here/tag-name
Look at page 224 of better builds with maven for more details
Nicole
On 06/02/2008, Benoit Decherf <[EMAIL PROTECTED]> wrote:
Hi,
I think that we should be able to perform a release from an old
nightly
tag rather than do it always from the trunk :
Every night functional tests run on a project A. On day "d"
everything
works, but after, I decide to add a feature and I broke the trunk.
I'd
like to be able to release the project in it's state of day "d"
without
losing the work I done. This could be useful in some cases.
Is there already a way to do it ?
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
