jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: Version file for oro...
Date Wed, 14 Apr 2004 01:22:11 GMT

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.


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

View raw message