I take it that you are arguing that since the POM changes then the
release jar has actually changed. This argument already assumes that
you're using a single version for specs. Do I understand correctly?
Regards,
Alan
On Oct 2, 2006, at 11:11 AM, [EMAIL PROTECTED] wrote:
Remeber now.... A release is jar + pom configuration.
--jason
-----Original Message-----
From: "Alan D. Cabrera" <[EMAIL PROTECTED]>
Date: Mon, 2 Oct 2006 06:51:20
To:[email protected]
Subject: Re: One version for specs
I don't think that this is a good idea. Versions should reflect the
contents of the jar not the fact that an unrelated spec was released/
patched/updated.
Regards,
Alan
On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
Hi, me again... and the specs topic again too.
I have been thinking about this for quite a while and I believe
that it would be in the best interest of the project to treat our
specs as a project and use one version to release the spec modules
under.
Doing so will greatly reduce the complexity to maintain the specs
tree and to make new releases. It also reduces the need for a
bunch of config in the root pom.xml for specs... all properties can
be removed and most of the dependencyManagement can be removed as
well.
Releases can be done using the release plugin with out any twists
of configuration, which should be straight forward. The
alternative is that the configuration becomes more compkicated and
that in order to make a release users will have to have much more
knowledge of how Maven works and how we have configured it... which
I am betting will only lead to something being missed which will
only lead to problems down the road.
One thing to remember for those of you who are gonna say that some
spec module has not changed in x-years... is that the release is
code + pom configuration... and even if the code has not changed,
the configuration has, and thus it warrants a new release to be made.
Specs do not get released that often anyways, so I don't really see
any huge problem with re-releasing specs under a new version when
something is added (or fixed).
1 version number for us (and our users) is IMO much, much simperer
than 30+ versions. For example, if I am a developer and want to
use the latest versions of all of the specs that I use, I would
much rather know that there is just one version to track, instead
of needing to hunt down what the latest version of each spec is...
after all I don't care what the version is... I just want the
latest version.
Also remember that some spec modules depend on other spec modules,
so ideally when a dependency module is released, the dependent
modules should be released to pickup the latest versions. Doing
this is automatic with the one-version scheme, but becomes much
more work with independent versions... which will almost certainly
result in dependent modules not getting updated as they should.
* * *
We have also been waiting for some resolution on this to simplify
the main server build. It will take all of 10 minutes for me to
fix the specs build to use one version and make a release than can
be used by the server build (and allow the bootstrap of specs to be
removed).
So, my recommendation is to:
1) change the specs project to use one version, 2.0-SNAPSHOT, and
publish the snaps
2) update the server build to use 2.0-SNAPSHOT for all specs
3) remove the specs build from bootstrap
I believe this is the best option for the project and community at
this point. I would like to implement this ASAP to simplify the
server build. If after some time folks do not feel that is working
well, then we can revisit and consider either splitting up into a
multi-trunk build or using independent version numbers. But, I do
believe that most will find that the advantages of using one
version far out-weight the disadvantages.
NOTE:
For those unaware, Dain did an experiment with version ranges...
but it looks like this will not work well right now as there is not
general support for use of ranges in most plugins that we depend
on. Also several members of the m2 team have suggested that ranges
are buggy. This was my general impression that I brought up to
Dain weeks ago when we talked about using ranges (and when he said
he would try it out). So, for now at least I think that ranges
will not work for us.
--jason
