Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
yes, I was too lazy to touch nearly every POM file in our repository
just to increase the version number of our parent POMs. I haven't done
this for the last release either and AFAICT, no problem occurred.
Hmmm, find, xargs and sed should do this work within one minute. :-)
it's a bit more difficult but in general yes.
Actually we already have such a script (tools/pom-updater) but still I
always managed to break the build.
Does anybody know if it can cause problems if the development version
number isn't increased after a release?
I would say that it's at least confusing. So how does this work now? We
have a new version of parent pom but we reference to the old one. Which
version is chosen finally?
All our POMs in snapshot mode refer to the (not-changing) cocoon-parent POM.
After writing this I see the potential problem: If we want to use some
of our own modules in their released versions, they would pull in the
released cocoon-parent POM. This could lead to some unwanted side-effects.
This means that if we want to use released versions of our own modules,
we have to increase the version number of cocoon-parent and should
follow Carsten's proposal and remove all intermediary POMs
(tools-modules, blocks-modules) except core-modules.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
________________________________________________________________________
