RE: Jakarta-Oro version...

Just some thoughts on an API (if implemented):

- Have a getFullVersion() that looks appealing in a single String.

- Have getMajorVersion(), getMinorVersion(), and getRevision(), or
getBuildNumber().

- Have the above return integers.

- Although I have no real pull either way, it seems to me all methods
should be static.

Thanks,
Two-bit-Tom :-)



-----Original Message-----
From: Daniel F. Savarese [mailto:[email protected]] 
Sent: Monday, April 05, 2004 11:13 AM
To: ORO Users List
Subject: Re: Jakarta-Oro version... 


In message
<418590005AFDB04DA77890F448295D43273D23@MAIL01.bedford.progress.com>
, "Thomas Mitchell, Jr." writes:
>We are using 2.0.4 presently and the manifest is essentially empty.  I
>just got the 2.0.8 jar and the maifest does have the version listed,
>thanks.

Ouch!  I checked the log and it doesn't look like we started adding
version info to the manifest  until 2.0.7-dev-1 :(

>I would vote to have a version class included, but simply for
>convenience.  I will not be using a different class loader depending on
>the oro version, I will only be using it for UI (display on our credits
>page) and assistance for QA and licensing.

Does anyone else have a desire for an org.apache.oro.Version class?
Any suggested APIs?  Should the methods be static; should there
be just one getVersion, or should there be additional getMajorVersion,
getMinorVersion, etc.; should they all return strings or should the
additional ones return ints, ...?

I wrote:
>package and use a different classloader when the version isn't
>acceptable.

I had meant to write "available" instead of "acceptable."

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]