I'm happy with Martin's original proposal, that, afaik, doesn't break anything. \pdftexversion will move like this: 130 140 150 160 170 180 190 (all A.BB), then 200 210 (A.B.C) and perhaps 211 if a bugfix release is needed. Right, Martin? Taco Martin Schröder wrote:
On 2005-06-08 09:05:41 +0200, Heiko Oberdiek wrote:
Thus I think, it is quite too late to change this interface.
No change is needed; currently \pdftexrevision is a char with alphanums, in the future it will be a char with digits. This shouldn't break anything.
Do we really need the information of \pdftexrevision as a number? It would be nice, but is it needed?
* Suggestion for interface that respects compatibility and adds an interface for three numbers:
A.B.C A \in [1..\infty] B \in [0..99] C \in [0..25]
The whole version number is printed as: printf("%d.%d.%d", A, B, C)
\pdftexmainversion: readonly integer for A \pdftexsubversion: readonly integer for B \pdftexbugfixversion: readonly integer for C
\pdftexversion := \pdftexmainversion * 100 + \pdftexsubversion \pdftexrevision := to_lowerletter(\pdftexbugfixversion)
Why?
[...]
Thus we have already A, B, and C. What we really need is rather a specification: * data type: A, B, C are numbers (/strings), range
A \in [1..\infty] B \in [0..99] C in "0".."9" (currently it's "a".."z"
B is only increased by 10.
* how does the version look like, formatting issues
A.BB.C
and the definition of semantics: * meaning of A, B, C
A and B have no meaning for themselves; together they are the current version. C is the patchlevel.
* when to increase A, B, or C
C is increased only for bug fixing releases.
A.B is increased by 0.1 by every release with new features.
Best regards Martin