Kalle Korhonen wrote:
Well, maybe you have a valid use case, but I don't think there's any support
for it. How do you create a nightly tag then? Couldn't you just run
release:prepare nightly, then run integration tests on the newly created
tag, and if succeeds, perform the release, otherwise abandon the tag. I
don't see a difference between a nightly tag and an "official tag" - you
could just use minor/micro version numbers to differentiate between
"official releases" and nightlies. Alternatively, if you use svn, you should
in principle be able to use revision number for this, but I don't think
there's any way to instruct Maven to checkout specific revision for
release:prepare rather than always using the head.
A nightly version is like a snapshot. It have to be deleted after some
days. It is just here to check that we are able to create valid version
every night and that nothing is broken. The nightly tag process is done
by continuum in our process.
I'm agree with you that revision number in svn could solve our problem,
but we need in all case to be able to create a release from an older
revision number and not the trunk (And anyway we are not yet using svn :( ).
So it would be great to add 1 option to maven release:prepare
(-DfromTag). If this option is set, maven should create a branch from
this version, checkout this branch and execute the standard release
process from it.
This also mean that scm:branch should be able to create a branch from an
older tag. (I think it is not possible to do it for the moment).
And as you said, it will be great to be able to create a release from a
specific revision number, so we wouldn't have to tag every night (for
the day we will migrate to svn:) )
I think that I could take some time to work on this improvement if you
accept it.
Benoit.
Kalle
On Feb 7, 2008 2:40 AM, Benoit Decherf <[EMAIL PROTECTED]> wrote:
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]
