As a user, it is a convenience to be able to have a single version
number to track across all the spec releases. So there's only one
variable to track.
However, I still don't think this is a very good approach. Our specs
tree will continue to expand with new JSRs and J2EE releases,
especially if we go with the earlier intent of making it a home for
all Apache Java spec packages. I don't like the idea that I'll have
10 versions of EJB 2.0 in my local repository, all with the same code,
and with different projects potentially using different revs depending
on how aggressive they are about needing new unrelated specs.
I think in the end, I'd rather have separate builds for separate specs
and an auto-generated or frequently updated web page with a table
listing all the specs with their JSR reference and the latest released
and snapshot versions of each. If I had to check that page for the
right numbers for each spec when building a new POM, that would be a
pretty close second to just having all of them use the same number
(which I'd still have to look up each time anyway). And it would mean
copy and paste dependencies on old specs like EJB 2 would be more
likely to be up to date.
But in the end, I don't feel super-strongly about it.
Thanks,
Aaron
On 10/1/06, Jason Dillon <[EMAIL PROTECTED]> 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
