Date: Mon, 31 May 2004 15:57:29 +0200 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Akinori MUSHA <knu@iDaemons.org> Cc: ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/databases/ruby-sqlrelay Makefile Message-ID: <40BB39C9.2060204@fillmore-labs.com> In-Reply-To: <86pt8k4t94.knu@iDaemons.org> References: <200405301418.i4UEIVnF072175@repoman.freebsd.org> <86r7t16wbf.knu@iDaemons.org> <40BAEB3C.6050200@fillmore-labs.com> <86pt8k4t94.knu@iDaemons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>patches. > > 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. -Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40BB39C9.2060204>