cvs commit: ports/databases/ruby-sqlrelay Makefile
eikemeier at fillmore-labs.com
Mon May 31 06:57:37 PDT 2004
Akinori MUSHA wrote:
> At Mon, 31 May 2004 10:22:20 +0200,
> Oliver Eikemeier wrote:
>>I read the commit log, but the PORTREVISION reset is pureley cosmetic,
>>so keeping it until the next release does not cause any problems.
>>OTOH it makes automatic version auditing possible, which guarantees
>>that tools like portupgrade will work. It is hard to check whether a
>>port is just broken on a single platform or automatically read commit
>>logs. If you want to have a version number going backwards, you can
>>always bump PORTEPOCH. Do you think we need another mechanism/flag to
>>signal automatic testing systems that everything is well? The script
>>I'm running is at ports/Tools/scripts/chkversion.pl, feel free to send
> The script issued a warning mail(s) nagging about the commit, and I
> made myself quite clear in the attached commit log. So, everyone on
> the ports@ list that read the mail could see that I knew what I was
> doing and I intentionally reset PORTREVISION. Thus the chkversion.pl
> script served its purpose. What's the problem? What made you think
> that you must commit the "fix" ?
The script would've nagged you every two hours until this has been
fixed. I guess you don't want that?
> I'm not opposing but just wondering.
No problem. A one-time reminder might get lost easily, and it's nice
to know that it has been fixed. I do not oppose the idea of letting
portversions going backwards intentionally, although I'm not happy with
what happened to dns/bind9 since October 2003. If we really want to
support that, we have to find a method to make this explicit in a way
that is machine parsable, which has not to be part of the PKGNAME,
but starts a new version numbering chain. IMHO a consistent ports tree
(with reliably working tools as a consequence) is worth more than
cosmetics like resetting PORTREVISION or PORTEPOCH. Correct me when
I'm wrong, but this is the version numbering scheme we have in
FreeBSD ports, and we should either adhere to it (including FreeBSD
amendments), or invent something new.
More information about the cvs-ports