geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <>
Subject Re: [VOTE] Specs organization, versioning, and releasing
Date Mon, 28 Aug 2006 15:58:02 GMT
+1 to releasing them all as one version #.

It will make everyones life easier (dev's and users) having one # to  
remember than many.



On Aug 27, 2006, at 5:50 PM, Jason Dillon wrote:

> I've implemented #5, which was to restructure to use the same
> directory and artifactIds... I renamed the directories to match.
> I think we need to have another round of discussion on how to handle
> the versioning.
> I'm starting to lean heavily towards having *one* version for *all* of
> the specs.  I don't care too much that if spec A makes a change that
> we release new versions of all of the other specs.  It is actually
> similar to the server, when a bugfix release is made, a bunch of
> modules will have no change since the last version, but we release
> them anyways because it is simpler for use to manage, and easier for
> users too, since they just need to know one version number... not the
> version number of each module.
> IMO, less version numbers to manage is easier... and better.  The side
> effect is that more artifacts get released when we cut a new version.
> But I don't see that we are going to be making tons of these spec
> releases... so I don't see any harm in the additional artifacts.
> So, my recommendation is to use one version for all of them.  I
> believe this will be best in the short to medium term at least, and if
> we find that it not working for the long run, then we can revisit
> later.  But right now I'd like to get a consistent release of these
> artifacts so we can remove the need for the bootstrap step to check
> them out and build them.
> I'd like to discus for a few days, create a new proposal, vote and
> then implement in the near future.
> Comments?
> --jason
> On 8/18/06, Jason Dillon <> wrote:
>> 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.
>> 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

View raw message