Jan Prikryl [EMAIL PROTECTED] writes:
Would it make more sense to put "1.7-dev" in this file and update it to 1.7
on release along with NEWS, doc/wget.texi, po/*.po, and src/version.c?
Probably.I thought about it when I wrote it, and I decided to put
right 1.7 there to "save the future editing". Well ... this argument
does not hold very much.
The problem of 1.7dev being the version of RPM is that AFAIK according
to the RPM versioning scheme, 1.7dev 1.7 so that when 1.7 is out, it
would not automatically replace any 1.7dev. In the moment when I find
out how to make this work, I'll replace it.
Actually, it's "1.7-dev", but I suppose that probably doesn't make a
difference, eh?
I guess this is an area where my preferred "old_version+dev" scheme would
work better than the "new_version-dev" currently being used. The main
reason I usually like the former is that you don't always know what the next
version will be. For instance, we didn't know if the version after 1.5.3
was going to be 1.5.4 or 1.6, so I made the version 1.5.3+dev ("1.5.3 plus
some development").
But I presume that the +dev scheme would work well with the RPM versioning
as well. It would consider (1.5.3, 1.5.3+dev, 1.6) to be in order, right?
In our particular current situation, of course, we're pretty sure of what
the upcoming versions are going to be, so 1.6.1-dev ("1.6.1 minus some
development") and 1.7-dev are more appropriate than usual. Also, if we were
using the +dev scheme with the current branched development, 1.6.1-dev would
of course be 1.6+dev, but what would 1.7-dev be? It sprung from the
1.5.3+dev sources without ever becoming 1.6.x, so it's not clear what you'd
call it. It would be unfortunate to leave it 1.5.3+dev, as significant
changes were made since the bulk of the 1.5.3+dev development. And you
couldn't call it 1.6+dev, since that's being used on the other branch. I
guess you'd have to give it a version you knew was never going to be used on
the stable branch, like 1.6.99+dev. Kinda wacky.
I could change 1.7-dev to this, but I suppose it's probably not worth it. I
guess we don't gain all that much from being able to have properly-sequenced
1.7 development and stable RPMs?
The files containing version number shall be somehow updated
automatically. But I have no clue how to do that without creating an
.in version of every file and feeding them to sed. Maybe using some
special comment lines and a good parser it could have been done.
Well, proliferation of .in files doesn't really bother me.
---
Dan Harkless| To help prevent SPAM contamination,
GNU Wget co-maintainer | please do not mention this email
http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
