Ciaran McCreesh posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 01 Nov 2005 01:51:25 +0000:
> ``Version:`` > Initially 1. Incremented every time a non-trivial change is made. > Changes which require a re-read of the news item should instead use a > new news item file. Very good work! This "Version" field calls to mind the MIMEVersion spec, and the ebuild version proposal, only here it's apparently used for news-item version. I'd suggest we preemptively incorporate an ENewsVersion or similar field as well, to be 1.0, with this proposal, but should the format ever need changed, that would allow for a format version 1.1 or 2.0 or whatever. As the GLEP suggests that future GLEPs may add new headers, this would allow them to update this version field as necessary, presumably using the familiar minor version = backward compatible, major version if not backward compatible, versioning scheme. You are very good at laying everything out in a just so spec, so I'll leave it to you to provide specific wording. =8^) One other niggle. The encoding is specified as UTF-8, but then the format is specified as RFC-822 (7-bit ASCII, pre-i18n) compatible. I'm not up on i18n specs, but presumably there's a newer RFC that specifies how internationalized internet messages are handled in an RFC-822 backward compatible way? If so, it may make more sense to reference that specific RFC, which presumably deals with UTF-8 instead of specifying 7-bit ASCII as does 822. Alternatively, MIME/Quoted-printable could be specified, which would allow for escaped 8-bit chars, as I'd /assume/ UTF-8 requires, given the -8. (I /said/ I'm not up on that!) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
