Hello,
2007/11/27, [EMAIL PROTECTED]
[EMAIL PROTECTED]
:
It sounds odd to have that many release version per day.
Yes indeed. Well, not per day, but per week. Nevertheless, it is odd.
Version range
notation would be perfect for what you need..
The first thing we will try is to use ranges
I don't remember exactly (and my list of mvn bookmarks aren't working as well
as they used to), but my recollection is if you put nothing for version number,
it depends on the metadata stored in your internal repository (as long as that
is kept up to date). Or was there a way to say use the
that only works for plugins, not for compile dependencies...
I have the same problem, but I do my versioning slightly different.
When I release my 1.0.0-SNAPSHOT, I'll make the release version
1.0.0.v20071126, and keep the development version at 1.0.0-SNAPSHOT...
Tom
On Nov 26, 2007 5:32 PM, EJ
If you are releasing something, I think it's wrong to force your clients to
move onto the new versions. If the client modules using your module would be
in control of what they use, they'd update versions in their own schedule,
even skip some. I haven't tried, but I wonder if it'd work to use both
Unfortunately what I suggested doesn't work because of
http://jira.codehaus.org/browse/MDEPLOY-44 - setting uniqueVersion from the
command line doesn't work together with deploy:deploy, only with
deploy:deploy-file - of course you could use the latter but it gets even
more cumbersome.
Kalle
On
It sounds odd to have that many release version per day. Version range
notation would be perfect for what you need..
i.e.,
[2.1, )
Having said that I found a number of problems with using version range and
I am stuck with 2.0.6 because 2.0.7 gives me NPE when it tries to resolve
conflict
