geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: [VOTE] Specs organization, versioning, and releasing
Date Tue, 29 Aug 2006 08:57:10 GMT
Kevan Miller wrote:
>
> On Aug 27, 2006, at 7: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?
>
> You've got my support... :-) One specs version is what I've proposed 
> in the past and would still like to see.
I'm generally in favor of it, with the possible exception of the 
javamail modules, which have shown a bit of churn when compared to the 
others.  Actually, I'm more of the opinion that the javamail spec 
modules don't really belong bundled with the other specs, because those 
modules are more implementation code than interface definition.  Pure 
interface specs tend to be a lot more version stable than actual 
functional code.

Rick


>
> --kevan
>
>


Mime
View raw message