Does anyone have a "Best Practice" already written for this?
From what I understand:
a) since releases are immutable, you can only deploy a release once.
b) you are allowed to deploy snapshots as often as you want
c) a human being needs to decide when you are starting to build releases.
d) you can use alpha, beta, release candidates RC1, RC2, RC3, etc. to
identify releases prior to a cleanly numbered release. Someone once
wrote a forum note about this, I think.
e) different parts of an application can be at different stages in a
release but this does create a need for careful management and some
consideration in a continuous build environment.
We got tired of (and ran out of time for) changing release numbers on
modules that did not change as fast as the application. For example, our
release 1.10 of the overall application depends on messaging utility
1.8.3 since the messaging utility has not changed since 1.8.3 was
released. We have over 60 projects in our portal application and only 3
people in development so we can not change and rebuild and rerelease 55
projects just because 5 modules got upgraded going from 1.9 to 1.10.
As we moved more functionality into services, we got more stability in
the modules and it appeared that we were spending too much time
redeploying modules with new versions and the same functionality.
We decided that it was alright for release 1.9 of the ContractAdmin war
to have a dependency on 1.8.3 of the messaging system jar.
We do have some aggregation jars that help manage this by creating a
single 1.10 OurLibraries jar that has the right dependencies of the
utilities such as messaging.
It does require a bit of planning and coordination where a decision to
add a function to the messaging utility to accommodate a new function in
a dependent module has to be addressed by the entire team and those
modules that use the messaging utility need to have their dependencies
changed and also need more testing than they might have got if they were
not changing or their dependencies were not changing.
Not sure how this relates to other environments and I do not think
that this is a candidate for a "Best Practice" until others have used it
and found that it solves a problem in a certain development environment.
It is probably not suitable for large teams where the cost of
coordination exceeds the cost of upgrading releases. For a small team,
where rereleasing 55 modules can be avoided
by a few extra question in 30 minute planning session and a 15 minute
review prior to going into test and a short conference or e-mail when a
module has to be changed that was not on the original list for the
release, this appears to work.
Ron
On 15/09/2010 6:09 AM, Bengt Rodehav wrote:
Thanks for your input Baptiste,
Yes, we have been debating the relase process a bit here. Keeping the relase
process separate would e g mean that we know beforehand that we want to
build a release candidate. We could then start with the tagging and then
checkout on this tag for the build of the release candidate.
Not quite sure what you mean by:
(even if, imo, if you're depending on a snapshot revision, and try
debugging a snapshot version that's not the dev version, you have a problem
in your dev process)
Our central, nightly builds do not use published snapshots but always checks
out from CVS and then build from source. I agree that if a central build
(that could be a release candidate) was built using published snapshots, we
would have a problem.
/Bengt
2010/9/15 Baptiste MATHUS<m...@batmat.net>
Yes, this is a typical, almost specific CVS problem that's understandable.
As the versioning is done at the file level, and not at the repo one, it
can
be necessary to tag to be able to identify the code corresponding to a
snapshot (even if, imo, if you're depending on a snapshot revision, and try
debugging a snapshot version that's not the dev version, you have a problem
in your dev process).
This problem doesn't exist with SVN. For example, we use the
buildnumber-maven-plugin and add the svn repository revision number to the
manifest for each build. So finding corresponding code for a jar is no
problem at all for us, but we actually hardly need it.
For the dev process, only in my opinion, I think automatically releasing
every nights isn't a very good pratice. I rather think the release process
should be actually 100% standalone, but *manually* initiated (giving the
new
version and so).
Cheers
2010/9/15 Bengt Rodehav<be...@rodehav.com>
We've had similar questions where I work. The question has been related
to
how and when to create tags in CVS (preferrably using the
maven-release-plugin).
Some people advocate tagging every build so that it can be recreated in
case
it was fit for delivery. This is a problem when using CVS since huge
number
of tags are not handled very well.
However, builds that could potentially become a released version must be
recreatable somehow which implies a tag in the version control system.
Whenever a "release candidate" is built, doesn't it have to be tagged -
and
therefore released?
When we enter a system testing period close to the release of a new
version.
We normally build and deploy new versions automatically every day. At
some
point we decide that it's good enough to release. It is then imperative
that
the latest build (which we have used for testing) is the one we package
and
tag.
What are the best practices around this? I'm very curious to know how
other
organisations handle this using maven.
/Bengt
2010/9/15 Baptiste MATHUS<m...@batmat.net>
Well, for example, we don't release automatically. We launch manually
it
via a special release plugin through hudson, itself launching a maven
release through the maven-release-plugin.
This makes it easier to keep a clean release environment. Releasing
from
a
development machine would add risk since it (1) might be less close to
the
production system and (2) might contain things depending on the dev box
that
wasn't added to the SCM.
Snapshot builds are totally sufficient for us to handle testing
purposes.
Cheers
2010/9/15 baz themail<bazthem...@gmail.com>
Hi,
I have been searching the maven website and articles but not sure if
i
get the best practice for managing snapshots and release.
Specifically, if continuous builds produce maven snapshot builds,
then
when will i produce maven release builds using maven release plug-in?
Will I ever produce a maven release build via an automated build job
that runs daily for example? The problem with that is: Because maven
plugin is incrementing pom.xml, and the automated build job will
always detect changes even tho there is no changes in the produce
software code. Does it even make sense? Or, release build should be
run manually depending on the release schedule?
Thank you.
A.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Baptiste<Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
--
Baptiste<Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
