Heiko Oberdiek wrote:

I would dislike the idea to have a complicate algorithm only to order pdfTeX versions.

indeed, all 'important' changes (primitives, features) should be reflected in on enumber;

* \pdftexversion and \pdftexrevision are accessed differently: \the\pdftexversion, but \pdftexrevision (expandable) And \pdfversion encodes two numbers.

Thus having three numbers instead of the current mixup improves the usage interface.

* Compatibility: * \pdftexversion is used in (TL2004): * ConTeXt * hyperref * graphicx/pdftex.def * pdfcprot * texinfo * fontinst * attachfile * pdfpages * thumbpdf * ... * \pdftexrevision is used: * hyperref * fontinst * pdfcprot * graphicx/pdftex.def * thumbpdf * ...

Thus I think, it is quite too late to change this interface.

an option is to freeze the old numbers and introduce new ones

* 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) to_lowerletter defines the following mapping: 0 -> a 1 -> b ... 25 -> z

The following conditions, expressed in TeX, hold:

\the\pdftexversion = \the\numexpr \pdftexmainversion * 100 + \pdftexsubversion\relax

\the\pdftexbugfixversion = \the\numexpr\expandafter`\pdftexrevision - `a\relax

* \pdftexmainversion, ... could be defined as macros, example with e-TeX, pdfTeX versions >= 1.0:

\edef\pdftexmainversion{% avoid division with rounding \number\dimexpr 0.01\dimexpr\the\pdftexversion sp\relax\relax } \edef\pdftexsubversion{% \number\numexpr \the\pdftexversion - 100*\pdftexmainversion\relax } \edef\pdftexbugfixversion{% \number\numexpr \expandafter`\pdftexrevision - `a\relax }

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 * how does the version look like, formatting issues

and the definition of semantics: * meaning of A, B, C * when to increase A, B, or C

i dislike the formal version number to be calculated, so i'd opt for: new primitives \pdftexmainversion: readonly integer for A \pdftexsubversion: readonly integer for B \pdftexbugfixversion: readonly integer for C backward compatibility primitives, not advertised \pdftexversion := \pdftexmainversion * 100 + \pdftexsubversion \pdftexrevision := to_lowerletter(\pdftexbugfixversion)

Next open issue of EuroTeX are feature tests. Some features cannot be tested by presence of pdfTeX primitives, eg. \ifeof18

actually, \ifeof18 is implemented now (at least it was the intention)

Thus currently only the version number can be used to test these features. Conclusion: * The documentation must contain a section that contains a mapping between a feature and the first version, where the feature is available. * Or new interface for feature checks independent of version numbers (and independent of a special TeX engine).

Thanks for the analysis -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Heiko Oberdiek wrote:

On Wed, Jun 08, 2005 at 09:26:12AM +0200, Hans Hagen wrote:

...

Heiko Oberdiek wrote:

i dislike the formal version number to be calculated, so i'd opt for:

new primitives

\pdftexmainversion: readonly integer for A \pdftexsubversion: readonly integer for B \pdftexbugfixversion: readonly integer for C

backward compatibility primitives, not advertised

\pdftexversion := \pdftexmainversion * 100 + \pdftexsubversion \pdftexrevision := to_lowerletter(\pdftexbugfixversion)

%%% test.tex %%% % simulate \pdftexmainversion, ... that are not yet defined \newcount\pdftexmainversion \pdftexmainversion=1 \newcount\pdftexsubversion \pdftexsubversion=21 \newcount\pdftexbugfixversion \pdftexbugfixversion=1

% now the code for \pdftexversion and \pdftexrevision follows. % It should probably go into pdftexconfig.tex \begingroup % * definition of \pdftexversion \count0=\pdftexmainversion \multiply\count0 by 100\relax \advance\count0 by \pdftexsubversion % using \chardef to avoid count register % and \the\pdftexversion must work \global\chardef\pdftexversion=\count0\relax % % definition of \pdftexrevision \count0=\pdftexbugfixversion \advance\count0 by `a\relax % the revision letter must have catcode 12 \lccode`0=\count0\relax \lowercase{\xdef\pdftexrevision{0}}% \endgroup

% test \message{* \the\pdftexversion\pdftexrevision} \end %%% test.tex %%%

sounds ok to me (some \ifx\undefined\pdftexversion is needed as wrapper so that we don't get problems due to mixups with older versions) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

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 -- http://www.tm.oneiros.de

On 2005-06-08 14:15:06 +0200, Taco Hoekwater wrote:

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?

Yes. Best regards Martin -- http://www.tm.oneiros.de

On Wed, Jun 08, 2005 at 11:52:05AM +0200, 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?

I do not mind if this is a character and thought there are some requests to have numbers.

...

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

There are some contradictions. Here the second B is always zero. Taco takes the second B as patchlevel, but what is \pdftexrevision then? Also already the tenth version forces the main version A to be incremented. Yours sincerely Heiko --

Hi,

...

...

...

...

"Heiko" == Heiko Oberdiek writes:

\pdftexmainversion: readonly integer for A \pdftexsubversion: readonly integer for B \pdftexbugfixversion: readonly integer for C

if you really intend to introduce new primitives, it would be better to call them \pdfmajorversion and \pdfminorversion instead of \pdftexmainversion and \pdftexsubversion. It's easier to remember because we already have \pdfoptionpdfminorversion. As far as compatibility is concerned, it's probably best to leave things as they are and add a new primitive \pdftexrevisionnumber. \pdftexversion is quite straightforward as it is now. It can easily be split into major/minor version. \pdftexrevision can be kept for backward compatibility. It returns a character. \pdftexrevisionnumber returns an integer. Internally (in pdftex, the program), it is most straightforward if the revision number is an integer rather than a character (maybe it already is). It can be used easily by printf to type the banner, and \pdftexrevisionnumber has nothing to do but return this integer. \pdftexrevision has to translate the number to a character. This is straightforward and absolutely backward compatible. I'd then vote for the following translation scheme: 0 => '' 1 => 'a' 2 => 'b' ... 26 => 'z' That means that a release has not automatically to be a bugfix release. We can have 1.30 instead of 1.30.0 if \pdftexrevisionnumber=0. \pdftexrevision expands to an empty string in this case. Cheers, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

On 2005-06-09 09:38:04 +0200, Hans Hagen wrote:

How many releases do we have per year, i.e. we may as well have enough resolution with those two numbers; currently we don't even use all of them; we can use the character number (c) as bug fix number, and use the current main version number as it is (a*100+b); we should be more generous in jumping numbers (so by now we should have had a.28 and not some 1.22w or so)

If I extrapolate for the last 12 months, - 1.20a would have been 1.20.0 (2004-09-06) - we would probably have a 1.20.1 (2004-10) - 1.20b would have been 1.30.0 (2004-12-22) - 1.21a would have been 1.40.0 (2005-02-04) - we would have done a 1.40.1 and 1.40.2 (and maybe even 1.40.3) - the next release would be 1.50.0 That gives us probably four "proper" releases a year and some bug fixing releases inbetween. I know that this doesn't look very stable, but we have some developement and we should aim at fixing bugs faster. Best regards Martin -- http://www.tm.oneiros.de

On Fri, Jun 10, 2005 at 09:40:45AM +0200, Hans Hagen wrote:

Martin Schröder wrote:

...

On 2005-06-09 09:38:04 +0200, Hans Hagen wrote:

...

How many releases do we have per year, i.e. we may as well have enough resolution with those two numbers; currently we don't even use all of them; we can use the character number (c) as bug fix number, and use the current main version number as it is (a*100+b); we should be more generous in jumping numbers (so by now we should have had a.28 and not some 1.22w or so)

If I extrapolate for the last 12 months, - 1.20a would have been 1.20.0 (2004-09-06) - we would probably have a 1.20.1 (2004-10) - 1.20b would have been 1.30.0 (2004-12-22) - 1.21a would have been 1.40.0 (2005-02-04) - we would have done a 1.40.1 and 1.40.2 (and maybe even 1.40.3) - the next release would be 1.50.0

That gives us probably four "proper" releases a year and some bug fixing releases inbetween.

I know that this doesn't look very stable, but we have some developement and we should aim at fixing bugs faster.

well, it may look unstable but at least shows more progress that linux kernel numbers -)

When will we go 2.00 ? when open type is present?

That's the problem with Martin's proposal, I think. * Never. My understanding of Martin is that we would have "2.0" rather than "2.00". Thus the confusion about version numbers remains. * We would go to 2.0 after 1.90 (or 1.90.x or 1.9x or 1.9x.y?)^1 regardless of some "main features" or "compatibility changes". We lost a semantics of the "main version number". ^1 Sorry Martin, probably I have got a brain damage after reading a lot of specifications (XPath, XSchema, XQuery, ...). I cannot think without a formal grammar specification. ;-( On Fri, Jun 10, 2005 at 01:42:43AM +0200, Martin Schröder wrote:

...

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?

Yes.

On Fri, Jun 10, 2005 at 01:48:41AM +0200, Martin Schröder wrote:

Starting with 1.30, B will be \in [30,40,50,60,70,80,90], starting with 2.0, B will be \in [0..9]. \pdftexrevision will always be in "0".."9".

...

Also already the tenth version forces the main version A to be incremented.

Yes. 1.90, 2.0, .. 2.9, 3.0 ..

I. What is a version number? What are the components of the complete version description? a) major version (A): major changes minor version (B): features added patchlevel (C): bug fix releases b) version (A.B) only and patchlevel (C) case a): a range [0..9] for B is too small in my opinion, it prevents more often releases. case b): a special meaning of A is lost and the version number is unnecessary complicate, just an integer would be enough. II. How the complete version number is encoded? \pdfversion, \pdfrevision, ...? 211 is unclear. Is 211 the number, given by \pdfversion? Does \pdfversion also contains the patchlevel and \pdfrevision is obsolete? Act versions < 2 and versions >= 2 differently in this respect? III. How the complete version number is displayed? 2.0 or 2.00 or 2.0.0 or 2.00.0 or 2.00a or 2.0a or ...? Yours sincerely Heiko --

On Fri, Jun 10, 2005 at 12:51:01PM +0200, Hans Hagen wrote:

Heiko Oberdiek wrote:

...

...

When will we go 2.00 ? when open type is present?

That's the problem with Martin's proposal, I think. * Never. My understanding of Martin is that we would have "2.0" rather than "2.00".

that's a display question, since it's actually version 200, displayed in the banner as 2.0.0 and when first debugged 2.0.1

...

Thus the confusion about version numbers remains. * We would go to 2.0 after 1.90 (or 1.90.x or 1.9x or 1.9x.y?)^1 regardless of some "main features" or "compatibility changes". We lost a semantics of the "main version number".

2.0.0 == 2.0 == 2 == 200 2.0.1 == 201 2.0.2 == 202 2.1.0 == 2.1 210

15.0.0 == 15.0 == 15 == 1500 15.0.1 == 1501

I try to define \thepdftexversion that generates the formatted version number: \begingroup \expandafter\ifx\csname pdftexversion\endcsname\relax \gdef\thepdftexversion{0.?}% UNCLEAR \else \ifnum\pdftexversion<100 % \xdef\thepdftexversion{0.\the\pdftexversion\pdftexrevision}% \else \ifnum\pdftexversion<130 % \def\gobble#1{}% \xdef\thepdftexversion{% 1.\expandafter\gobble\the\pdftexversion\pdftexrevision }% \else \ifnum\pdftexversion<200 % \def\gobble#1{}% \xdef\thepdftexversion{% 1.\expandafter\gobble\the\pdftexversion.\number\pdftexrevision }% UNCLEAR \else \count0=\pdftexversion \divide\count0 by 100 % \xdef\thepdftexversion{\the\count0}% \multiply\count0 by -100 % \advance\count0 by \pdftexversion \edef\x{\ifnum\count0 < 10 0\fi\the\count0}% \def\y#1#2{#1.#2}% \xdef\thepdftexversion{\thepdftexversion.\expandafter\y\x}% \fi \fi \fi \fi \endgroup \message{ <<\thepdftexversion>> } \end

...

Sorry Martin, probably I have got a brain damage after reading a lot of specifications (XPath, XSchema, XQuery, ...). I cannot think without a formal grammar specification. ;-(

Xquery is indeed good for brain damage (interesting that those who oppose tex's mix of typesetting and programming state may favor something xquery -)

It's lecture stuff that I have to learn. It was interesting to see, how the query language evolved. Some time ago I had made a talk about the predecessor Quilt. In two weeks we are dealing with XSLT. Yours sincerely Heiko --