geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: What is the deal with geronimo-javaee-deployment_1.1MR3_spec
Date Fri, 30 Mar 2007 02:23:31 GMT
On Mar 29, 2007, at 6:35 PM, Aaron Mulder wrote:
> For what it's worth, Jason's proposal sounds reasonable to me*.  But I
> don't really fancy changing all the current names either.  :)

I don't really want to change them (ie the work)... but I feel very  
strong about getting rid of that version muck in the artifactId.


> * Well, I can't say that 1.1MR3-1-SNAPSHOT made sense at first glance,
> but the 1.1MR3-1 followed by 1.1MR3-2 seems clear.

Ya, seems weird at first, but I was just mapping David's example,  
which was for a SNAPSHOT ;-)

--jason


> On 3/29/07, Jason Dillon <jason@planet57.com> wrote:
>> On Mar 29, 2007, at 8:06 AM, David Jencks wrote:
>>
>> > artfifactId=geronimo-javaee-deployment_1.1MR3_spec
>> > version=1.0-SNAPSHOT (IIRC, but its' value is irrelevant)
>> > groupId=org.apache.geronimo.specs
>> >
>> > the spec version is 1.1MR3
>> >
>> > It follows the agreed upon conventions for geronimo spec naming.
>>
>> I think we should reconsider the convention.  And use the artifacts
>> version to contain *all* of the version information.  Since the
>> current convention's version is mostly irrelevant anyways, I suggest
>> that we use the spec's version + revision number (counter) as the
>> version.
>>
>> That makes the above look like:
>>
>>      artfifactId=geronimo-javaee-deployment-spec
>>      groupId=org.apache.geronimo.specs
>>      version=1.1MR3-1-SNAPSHOT
>>
>> And when released the version would be:
>>
>>      version=1.1MR3-1
>>
>> This indicates the spec version and a revision count for how many
>> update/iterations we have applied to it.  When its time to make a new
>> revision then we'd have:
>>
>>      version=1.1MR3-2
>>
>> And when the spec version changes to say 1.2, then we'd have:
>>
>>      version=1.2-1
>>
>> IMO this is *much* more natural and allows us to use the Maven
>> dependencyManagement section to manage all version information
>> effectively for child modules.
>>
>> --jason
>>
>>
>>
>>
>>
>>


Mime
View raw message