dev@glassfish.java.net

Re: right way to use version numbers for modules

From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Sun, 16 Mar 2008 12:30:59 -0700

Hi Sahoo,

I think that version numbers on modules should be globally consistent
and posted to a wiki page so everyone knows what they are.

It would be nice if the numbering scheme reflected some uniform
criteria: modules being developed would always have a SNAPSHOT suffix.
Modules with a new JSR would have a major (first number) bump from
previous. Modules with a maintenance release would have a minor bump.
Modules that had bug fix maintenance that was not part of a JCP
maintenance review would have a third level bump.

I'm not saying that the above should be adopted verbatim, but that
someone in authority put their rules out and publicly encourage
projects to adopt them. Bill? Eduardo?

Craig

On Mar 16, 2008, at 6:27 AM, Sahoo wrote:

> Lloyd L Chambers wrote:
>> I'm confused about version numbers in modules.
> I think many people would agree with you.
>>
>> For example, I see the following in api/management/pom.xml:
>> <groupId>javax.management.j2ee</groupId>
>> <artifactId>management-api</artifactId>
>> <version>1.1-1-SNAPSHOT</version>
>> <name>Java EE Management API</name>
>>
>> Then in api/javaee/pom.xml under <properties> I see:
>> <management-api.version>1.1</management-api.version>
>>
>>
>> Are these two different animals?
> Yes. The latter one refers to a released(unmodifiable) artifact,
> where as the former one is under development. The only thing that's
> changing at this point of time is the manifest file entries, I
> believe.
>> What is the right way to make a dependency? For example, common/
>> amx-api wants to depend on manag
>> <dependency>
>> <groupId>javax.management.j2ee</groupId>
>> <artifactId>management-api</artifactId>
>> <version>${management-api.version}</version>
>> <scope>provided</scope>
>> </dependency>
>>
> The property should be changed to use the version being developed.
>
> We don't seem to be paying sufficient attention to these tricky
> details of Maven, which I am sure will bite us back in future. Maven
> appears easy to use, but the power it provides certainly demands
> more discipline.
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!