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