|
From: | Bastiaan Veelo |
Subject: | Re: bnv_have_qt |
Date: | Sat, 15 Jan 2005 22:46:00 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 |
Peter Simons wrote:
Hi Bastiaan, I fixed a minor syntax glitch that the SGML parser uncovered and ran another update. It will be online soon.
That is cool. BUT, would I have been able to generate the HTML myself, I could have visually checked the result and verified it with the CERN tools. I am kind-of coding blindfolded right now :-( Whatever tool is going to be used to generate the documentation in the future, I think it is a must that it can be run by macro contributors. It should be open source and straight forward.
Yes, it is intentional. Version numbers are another tricky issue. We talked about that a while ago, and my conclusion is that version numbers need to be incremented by hand. I am pasting in from your mail dated 2004/09/28 followed by my reply on the same day:By the way: Is in intentional that you aren't using the CVS $Id$ tag to provide the version of the macro? I didn't bump your version now, because the differences are only in the meta-data, but per CVS the macro has version 1.14 now. Peter
Peter Simons wrote:
The archives on SourceForge.net and gnu.org run on the same CVS repository of macros, hence they should _always_ both have the same version numbers. That doesn't mean I am a fan of CVS keywords, I just wanted to point out that your macro does unfortunately break that rule because, well, here both archives are _not_ using the same version. If that were remedied, there would be no inherent problem with using CVS keywords.
The inherent problem is that when John Doe has downloaded a macro whos version is defined with a CVS keyword, incorporated it into his project, committed it to his repository, that version number changes to something like "1.0, doe". Then, 6 months later, he encounters a problem with the macro. He goes back to check the archive. But, having forgotten what the version number was like when he downloaded (probably never looked at it) the version mentioned in the archive has no meaning. Downloading and diffing is the only thing he can do.
That is bad enough. But if there are more than one archive and they are not in sync, and John is unsure where he got it from (maybe he got there through Google, and now Google presents a different one at the top of the list) he may actually diff his macro against a version that is older, and downgrade while thinking that he is upgrading!
This is not far-fetched: one of my users got his macro through Google, and I myself had to assess the differences between my macro's in the two archives to determine which one was the newest.
[Prev in Thread] | Current Thread | [Next in Thread] |