Re:revisiting fVersion in light of static mutability

[Shane Curcuru <sh...@yahoo.com>]

You're definitely right in deprecating fVersion and removing as soon as
possible.

The only other suggestion, since you're moving this to a new location
anyway, is to think on the larger subproject level and make it:

String org.apache.xerces.Version.getVersion()

There was a call at some point in the past for all Apache subprojects
to provide a simple version string like this in a package called
org.apache.subprojectname.Version.getVersion() so that it would be
easily discoverable.  I'm not sure if this fits in with how the parser
is architected these days, but it might be worth thinking about.

(i.e. can someone have version x.y of the 'whole Xerces-J project', but
somehow have version p.q of a specific parser implementation within
that version of Xerces-J?)

=====
- Shane

<eof .sig="'When I use a word,' Humpty Dumpty said, 
in a very scornful tone, 'it means just what I 
choose it to mean - neither more nor less'"
"Oohayu oyod?!"=gis. />

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org