geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dillon" <ja...@planet57.com>
Subject Re: [VOTE] Specs organization, versioning, and releasing
Date Tue, 24 Oct 2006 22:53:14 GMT
Folks... this vote has been lingering for way to long... some of the
in-flight debate/discussion kinda threw us off track.

I believe that we should implement the solution we have described here
for now and if needed continue discussion and debate about how to
handle this better... BUT, I think we must do something now and I
think that this is good enough.

Here is a tally of the votes cast so far:

<snip>
+1: jdillon, dblevins, dain, bsnyder, bdudney, gnodet, pmcmahan,
jbohn, rmcguire, hogstrom
+0: jacek

And after some debate:
+1: kevan, alan
</snip>

While I, djencks, kevan and a few others have expressed some desire
for one version for all specs, and many other have expressed
objection... I do believe that we need to do something to get specs
into a publishable state NOW.

So, unless anyone screams loudly, I am going to implement the changes
described below as an intermediate solution.  Once this is done (and
once people comes back to life) we can publish a new set of SNAPSHOT
artifacts and remove the need for the specs build in bootstrap...
which is one step closer to not needing bootstrap.

This may not be the final solution... but its one step closer... and
since we have not moved at all on this for quite some time I think any
movement is better than none at all.

--jason


On 8/18/06, Jason Dillon <jason@planet57.com> wrote:
> PROPOSAL:
>
> 1.  Each spec will no longer be split up into trunk+branches+tags.
> There will instead be one trunk+branches+tags for all specs laid out
> as follows:
>
>      specs/trunk/pom.xml
>      specs/trunk/<artifactId>
>      specs/tags/<artifactId>-<version>
>      specs/branches/
>
> 2.  Each plugin will continue to have its own version and will be
> released independently.
>
> 3.  The top-level will have it's own version, which will remain
> independent.  When there is a major configuration change in that pom,
> the version will be changed and the pom will be republished.
>
> 4.  Releasing will be done with the maven release plugin ('mvn
> release') and should occur at a stable point after any major change
> to a spec module.
>
> 5. Change all module directories to match artifactIds.
>
> MOTIVATION:
>
> 1.  one trunk allows the entire set of specs to be checked out all at
>      once and built all at once.
>
>   * * *
>
> [ ] +1 Allow changes
> [ ] 0  No opinion
> [ ] -1 No, leave the specs asis (provide rationale)
>
> --jason
>
>

Mime
View raw message