geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Organization and versioning of specs; a new proposal
Date Fri, 11 Aug 2006 19:41:52 GMT
This is a good idea. I like it.

+1

Cheers
Prasad

On 8/11/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> Sounds fine to me.
>
> Thanks,
>      Aaron
>
> On 8/11/06, Jason Dillon <jason@planet57.com> wrote:
> > A while ago there was talks about independently versioning specs, and
> > Alan started a reorg branch which gives each spec module its own trunk
> > +branches+tags...
> >
> > I have been thinking about this for a while, and with the recent
> > desire to split off more modules from geronimo/trunk I've been
> > pondering it even more.  What I have come to believe is that spitting
> > up spec modules into their own trunk+branches+tags is probably not
> > the best direction for us to head in.
> >
> > I believe that all of our specs can, and should, share one trunk...
> > and still have each module specify its own version.  This is very
> > similar to how Maven2 plugins is setup, see here:
> >
> >      http://svn.apache.org/repos/asf/maven/plugins
> >
> > Each plugin has its own version that changes independently.  The top-
> > level pom has a version too, which is independent and is only changed
> > when there is a major configuration change in that pom.
> >
> > I recommend that we follow this model for our specs.
> >
> > The advantage to one trunk, is that it facilitates easy check out and
> > building when you just want all of the specs.  If each spec was in
> > its own trunk, you would need to svn co each one, then mvn install in
> > each tree, which is a pain.
> >
> > We also almost never branch specs, they just keep chugging along,
> > only really needing tags to track released versions.
> >
> > So, here is what I propose:
> >
> >      specs/trunk/pom.xml
> >      specs/trunk/<artifactId>
> >      specs/tags/<artifactId>/<version>
> >
> > And if needed:
> >
> >      specs/branches/<artifactId>/<name>
> >
> > This is a single trunk so to build all specs:
> >
> >      svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
> >      cd specs
> >      mvn install
> >
> > To release an individual spec, say geronimo-spec-jms:
> >
> >      cd specs/geronimo-spec-jms
> >      mvn release
> >
> > The m2 release plugin can be configured with a _tag base_, which we
> > can set to:
> >
> >      https://svn.apache.org/repos/asf/geronimo/specs/tags/$
> > {pom.artifactId}
> >
> > When released, the plugin will svn cp just the module's directory
> > into a directory under tags, so it will be easy to see what the
> > released versions of a specific spec are.
> >
> >   * * *
> >
> > I really do not see the need for each spec to have its own trunk, and
> > really I think that if we did then it would just make it more
> > difficult for cases when we really want all specs.
> >
> > I do not see any downside to the approach above.
> >
> > I recommend that we implement this.  The only major change, which
> > isn't that major, is that the properties which live in the root pom
> > that control the versions need to be removed... or rather moved back
> > to the <version> element of the respective pom.
> >
> > Comments?
> >
> > --jason
> >
> >
>

Mime
View raw message