geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Tue, 24 Jan 2006 23:13:34 GMT
[ ] Change all configIds to 1.0 even though it's the 1.0.1 release
[ ] Change all references to use no version and make that work
[X] Something else (please explain)

I like Matt's proposal.

John

Matt Hogstrom wrote:
>
>
> Aaron Mulder wrote:
>> All,
>>
>> There was some IRC talk but not a lot of list response to the configId
>> versioning issue.  Right now, it's kind of holding up 1.0.1 IMHO
>> because I can't support releasing 1.0.1 until we resolve the
>> compatibility issue somehow, and there's going to be a fair bit of
>> work to get it going one way or another.  Anyway, for the 1.0.1
>> release, please indicate your preference for:
>>
>> [ ] Change all configIds to 1.0 even though it's the 1.0.1 release
>> [ ] Change all references to use no version and make that work
>> [X] Something else (please explain)
> I think option two is the right way to go but would prefer for the 
> long haul to:
>
> 1. Change the format to geronimo/foo/car[/version] as it makes more 
> sense visually
>
> 2. Honor existing 1.0 plans but issue a deprecation warning.  Current 
> plans would be translated from geronimo/foo/1.0/car to geronimo/foo/car
>
> I'm not sure of the ramifications of changing the format at this point 
> but long term I believe it is the right thing to do.
>
>>
>> For the second option, that means the configId for module would still
>> be geronimo/foo/1.0.1/car but any parentId, import, or GBean reference
>> would look like this:
>>
>> parentId="geronimo/foo//car"
>> <import>geronimo/foo//car</import>
>> <import>
>>   <groupId>geronimo</groupId>
>>   <artifactId>foo</artifactId>
>>   <type>car</type>
>> </import>
>>
>> That is, the version would be omitted from the reference, and we'd
>> somehow interpret that to mean "whatever version is present" or "use
>> most current version".  You still *could* use a specific version, we'd
>> just emphasize the version-less option for maximum compatibility.  I
>> think this alternative would require more work but might be a better
>> fit for a long-term strategy.
>>
>> Thanks,
>>    Aaron
>>
>>
>>
>


Mime
View raw message