jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mitchell, Jr." <tmitc...@progress.com>
Subject RE: Version file for oro...
Date Fri, 16 Apr 2004 13:28:09 GMT
Daniel,

	Having isBeta() and isAlpha() (if the products actually have
alpha releases) and such is a good idea.  Sorry I missed that in my
submission.  Other things to keep in mind:
Do any of the products have pre-releases?
Do any of the products have patches, or service packs?
Others? (your isReleaseCandidate() may be useful to someone...)

	About your tweak.  Are you saying you would like users to be
able to create a Version class so they can create their own version of
<something>, but in the Jakarta format?  That sounds obscure, but
flexible, and potentially dangerous.  Even so, that I would vote for.

	You are way ahead of me on the architecture of the various
projects, so please excuse my ignorance.  I would like to make sure
users don't hang themselves somehow.  From a user perspective, version
information is generally query only; a one-way street.  From an AP
perspective, creating a version with the Jakarta format may have some
use.  As long as the shipped products can have clearly defined lines
between their version getter and the generic version creator (so to
speak), I think it's a great idea.  Clear javadoc will help.

My two cents (maybe four).
Tom


-----Original Message-----
From: Daniel F. Savarese [mailto:dfs@savarese.org] 
Sent: Tuesday, April 13, 2004 9:22 PM
To: ORO Developers List
Subject: Re: Version file for oro... 


In message
<418590005AFDB04DA77890F448295D43273ED0@MAIL01.bedford.progress.com>
, "Thomas Mitchell, Jr." writes:
>	I was unsure if I am allowed to send attachments to the list, as
>I am new to the dev list, so I simply copied my version of this class

Text attachments should be fine.

>	I'm not sure if I 'named' the various pieces of the version
>correctly, so please change to taste.  This class can go in
>org.apache.oro or org.apache.oro.util.  Also, the getFullVersion()
>method text should be changed to return a String more to your liking,
>maybe with a reference to the license?  I'm kinda winging it here....

I think it looks fine.  Since no one else has commented on
it, I'm inclined to just check it in.  However, since I have some
tweaks in mind, I'd like to air them before acting on them.  First,
how should we handle the convention some projects have, that ORO
mimicked, of doing an x.x.x-dev-1 release?  Should we abandon
the -dev convention in favor of something else or just change
buildNumber to a string?  Should we incorporate the notions of
beta and alpha with isBeta() and isAlpha() methods or
isReleaseCandidate()
or isFinal() or isDevelopment()?

Now, my tweak.  How do people feel about getting rid of the static
methods and members?  How about we make Version a regular class
with constructor arguments that you fill in to define the version.
Then maybe we'd just implement an OROVersion class that had a static
final method:
  Version getVersion()
that would return the version.  And maybe we put Version in oro.util the
way Thomas initially suggested.  Why would you want to do this?  Well,
it allows other projects to use the Version class for their own
purposes.
You could argue that a Version class should reside in Jakarta Commons.
I
think it's okay if we keep it here and then move it into Commons later.
Something to look into is whether the maven or repository projects or
jakarta commons have version-related classes.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org


Mime
View raw message