geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: One version for specs
Date Mon, 02 Oct 2006 17:35:38 GMT
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 <jason@planet57.com> 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
>
>
>

Mime
View raw message