You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by David Schulze <da...@delorme.com> on 2002/07/11 17:00:50 UTC
RE: Xerces versioning policies: re version definition in XercesDe
fs.hpp && Outstanding Bug 9154
I suggest using a static const of some class or a global const in some
namespace, not a DEFINE.
>#define _XERCES_VERSION (XERCES_VERSION_MAJOR * 10000 +
XERCES_VERSION_MINOR
>* 100 + XERCES_VERSION_REVISION)
-----Original Message-----
From: Robert Buck [mailto:rbuck@mathworks.com]
Sent: Thursday, July 11, 2002 10:59 AM
To: xerces-c-dev@xml.apache.org
Subject: RE: Xerces versioning policies: re version definition in
XercesDe fs.hpp && Outstanding Bug 9154
Alby and Tinny, (anyone else) please comment on who may define such a
policy. I think Jesse's idea [below] is a good one. But it does need to be
deliberate and well documented, as he suggests.
At 10:14 AM 7/11/2002 -0400, you wrote:
>I'm not sure who should make such a decision. It doesn't feel weighty
enough
>to require a vote of committers, but it's not totally trivial, either. I've
>reviewed the new XercesVersion.hpp file, and it's clear that if this change
>is made, it will affect *all* references to version numbers from here on
in,
>not just _XERCES_VERSION.
Anybody else listening in to this conversation... Who would make this
decision? Alby, Tinny?
>If it's desirable to allow for more than 10 minor versions and/or
revisions,
>but there's reason to leave the string constants in their current minimal
>form, I think we could accommodate that. We'd leave the base constants
>(XERCES_VERSION_...) as they are, and continue to concatenate them to
>produce derived string constants, but use math to transform them into the
>numeric form. For instance, if we want to allow two digits for minor
>versions and revisions, we could do something like:
>
>#define _XERCES_VERSION (XERCES_VERSION_MAJOR * 10000 +
XERCES_VERSION_MINOR
>* 100 + XERCES_VERSION_REVISION)
Hey, if it works. I think this is a fine idea.
>(I'm sure I'll be put on notice if this is a lame idea.)
>
>For what it's worth, I doesn't matter to me whether there's one digit or
>two, or what format the string constants have. I do, however, think it's
>important that the decision and its rationale be recorded in
>XercesVersion.hpp, so it will be understood by those who follow.
Agreed.
>I agree that there's no need to stipulate a number of digits in the major
>version number.
>
>-jesse-
>
>-----Original Message-----
>From: Robert Buck [mailto:rbuck@mathworks.com]
>Sent: Thursday, July 11, 2002 9:11 AM
>To: xerces-c-dev@xml.apache.org
>Subject: Xerces versioning policies: re version definition in
>XercesDefs.hpp && Outstanding Bug 9154
>
>
>Point well taken. Who are the right people to help decide such a policy?
>
>I think we could get by simply by stating that minor version numbers and
>revision numbers MUST have two digits in the version header file. Right?
>The requirement is not necessary , I think, for major version numbers.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Xerces versioning policies: re version definition in
XercesDe fs.hpp && Outstanding Bug 9154
Posted by Robert Buck <rb...@mathworks.com>.
Nope. Saying "no" does not imply that a static/global const could not be
provided. As Urs says, the DEFINE is more general. Taking a look at my
version header, you will notice that if _XERCES_VERSION were configured in
this way [the way Jesse suggests], you still are provided with these
automatically:
const char* const gXercesVersionStr = XERCES_VERSIONSTR;
const char* const gXercesFullVersionStr = XERCES_FULLVERSIONSTR;
const unsigned int gXercesMajVersion = XERCES_VERSION_MAJOR;
const unsigned int gXercesMinVersion = XERCES_VERSION_MINOR;
const unsigned int gXercesRevision = XERCES_VERSION_REVISION;
We could add an additional numeric constant as in:
const unsigned int gXercesRevision = _XERCES_VERSION ;
,which would satisfy your requirement too and probably would be a really
good idea to have around.
FYI: take a look at the machinery that generates these numbers in
version.h. You cannot do that easily with constants can you? The
requirements were:
(a) make it easier/simpler to change version numbers
(b) at most a developer must only have to change three values
(c) it must spit out numeric and string constants to be backwards compatible
-Bob
At 11:00 AM 7/11/2002 -0400, you wrote:
>I suggest using a static const of some class or a global const in some
>namespace, not a DEFINE.
>
> >#define _XERCES_VERSION (XERCES_VERSION_MAJOR * 10000 +
>XERCES_VERSION_MINOR
> >* 100 + XERCES_VERSION_REVISION)
>
>-----Original Message-----
>From: Robert Buck [mailto:rbuck@mathworks.com]
>Sent: Thursday, July 11, 2002 10:59 AM
>To: xerces-c-dev@xml.apache.org
>Subject: RE: Xerces versioning policies: re version definition in
>XercesDe fs.hpp && Outstanding Bug 9154
>
>
>Alby and Tinny, (anyone else) please comment on who may define such a
>policy. I think Jesse's idea [below] is a good one. But it does need to be
>deliberate and well documented, as he suggests.
>
>At 10:14 AM 7/11/2002 -0400, you wrote:
> >I'm not sure who should make such a decision. It doesn't feel weighty
>enough
> >to require a vote of committers, but it's not totally trivial, either. I've
> >reviewed the new XercesVersion.hpp file, and it's clear that if this change
> >is made, it will affect *all* references to version numbers from here on
>in,
> >not just _XERCES_VERSION.
>
>Anybody else listening in to this conversation... Who would make this
>decision? Alby, Tinny?
>
>
> >If it's desirable to allow for more than 10 minor versions and/or
>revisions,
> >but there's reason to leave the string constants in their current minimal
> >form, I think we could accommodate that. We'd leave the base constants
> >(XERCES_VERSION_...) as they are, and continue to concatenate them to
> >produce derived string constants, but use math to transform them into the
> >numeric form. For instance, if we want to allow two digits for minor
> >versions and revisions, we could do something like:
> >
> >#define _XERCES_VERSION (XERCES_VERSION_MAJOR * 10000 +
>XERCES_VERSION_MINOR
> >* 100 + XERCES_VERSION_REVISION)
>
>Hey, if it works. I think this is a fine idea.
>
>
> >(I'm sure I'll be put on notice if this is a lame idea.)
> >
> >For what it's worth, I doesn't matter to me whether there's one digit or
> >two, or what format the string constants have. I do, however, think it's
> >important that the decision and its rationale be recorded in
> >XercesVersion.hpp, so it will be understood by those who follow.
>
>Agreed.
>
>
> >I agree that there's no need to stipulate a number of digits in the major
> >version number.
> >
> >-jesse-
> >
> >-----Original Message-----
> >From: Robert Buck [mailto:rbuck@mathworks.com]
> >Sent: Thursday, July 11, 2002 9:11 AM
> >To: xerces-c-dev@xml.apache.org
> >Subject: Xerces versioning policies: re version definition in
> >XercesDefs.hpp && Outstanding Bug 9154
> >
> >
> >Point well taken. Who are the right people to help decide such a policy?
> >
> >I think we could get by simply by stating that minor version numbers and
> >revision numbers MUST have two digits in the version header file. Right?
> >The requirement is not necessary , I think, for major version numbers.
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> >For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Xerces versioning policies: re version definition in
XercesDe fs.hpp && Outstanding Bug 9154
Posted by Alberto Massari <al...@exln.com>.
At 11.00 11/07/2002 -0400, you wrote:
>I suggest using a static const of some class or a global const in some
>namespace, not a DEFINE.
It must be a #define, and a numeric one, or you cannot tell the compiler to
use different code when dealing with different versions. For instance,
version 2.0 will move DOM headers into a "deprecated" directory, so you
need to write
#if _XERCES_VERSION >= 0x0200
#include <xercesc/deprecated/DOM/DOM.hpp>
#else
#include <xercesc/DOM/DOM.hpp>
#endif
As for the format (using 0x020000, or 20000), it doesn't really matter, as
long as it works....
Alberto
> >#define _XERCES_VERSION (XERCES_VERSION_MAJOR * 10000 +
>XERCES_VERSION_MINOR
> >* 100 + XERCES_VERSION_REVISION)
>
>-----Original Message-----
>From: Robert Buck [mailto:rbuck@mathworks.com]
>Sent: Thursday, July 11, 2002 10:59 AM
>To: xerces-c-dev@xml.apache.org
>Subject: RE: Xerces versioning policies: re version definition in
>XercesDe fs.hpp && Outstanding Bug 9154
>
>
>Alby and Tinny, (anyone else) please comment on who may define such a
>policy. I think Jesse's idea [below] is a good one. But it does need to be
>deliberate and well documented, as he suggests.
>
>At 10:14 AM 7/11/2002 -0400, you wrote:
> >I'm not sure who should make such a decision. It doesn't feel weighty
>enough
> >to require a vote of committers, but it's not totally trivial, either. I've
> >reviewed the new XercesVersion.hpp file, and it's clear that if this change
> >is made, it will affect *all* references to version numbers from here on
>in,
> >not just _XERCES_VERSION.
>
>Anybody else listening in to this conversation... Who would make this
>decision? Alby, Tinny?
>
>
> >If it's desirable to allow for more than 10 minor versions and/or
>revisions,
> >but there's reason to leave the string constants in their current minimal
> >form, I think we could accommodate that. We'd leave the base constants
> >(XERCES_VERSION_...) as they are, and continue to concatenate them to
> >produce derived string constants, but use math to transform them into the
> >numeric form. For instance, if we want to allow two digits for minor
> >versions and revisions, we could do something like:
> >
> >#define _XERCES_VERSION (XERCES_VERSION_MAJOR * 10000 +
>XERCES_VERSION_MINOR
> >* 100 + XERCES_VERSION_REVISION)
>
>Hey, if it works. I think this is a fine idea.
>
>
> >(I'm sure I'll be put on notice if this is a lame idea.)
> >
> >For what it's worth, I doesn't matter to me whether there's one digit or
> >two, or what format the string constants have. I do, however, think it's
> >important that the decision and its rationale be recorded in
> >XercesVersion.hpp, so it will be understood by those who follow.
>
>Agreed.
>
>
> >I agree that there's no need to stipulate a number of digits in the major
> >version number.
> >
> >-jesse-
> >
> >-----Original Message-----
> >From: Robert Buck [mailto:rbuck@mathworks.com]
> >Sent: Thursday, July 11, 2002 9:11 AM
> >To: xerces-c-dev@xml.apache.org
> >Subject: Xerces versioning policies: re version definition in
> >XercesDefs.hpp && Outstanding Bug 9154
> >
> >
> >Point well taken. Who are the right people to help decide such a policy?
> >
> >I think we could get by simply by stating that minor version numbers and
> >revision numbers MUST have two digits in the version header file. Right?
> >The requirement is not necessary , I think, for major version numbers.
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> >For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org