From owner-freebsd-doc Sun Mar 10 1: 0:16 2002 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DBBC637B416 for ; Sun, 10 Mar 2002 01:00:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2A905u96252; Sun, 10 Mar 2002 01:00:05 -0800 (PST) (envelope-from gnats) Date: Sun, 10 Mar 2002 01:00:05 -0800 (PST) Message-Id: <200203100900.g2A905u96252@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Dima Dorfman Subject: Re: docs/35620: make release fails in documentation for RELEASETAG=RELENG_4_5 as of Feb 28th Reply-To: Dima Dorfman Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/35620; it has been noted by GNATS. From: Dima Dorfman To: "Bruce A. Mah" Cc: freebsd-gnats-submit@freebsd.org Subject: Re: docs/35620: make release fails in documentation for RELEASETAG=RELENG_4_5 as of Feb 28th Date: Sun, 10 Mar 2002 08:59:48 +0000 "Bruce A. Mah" wrote: > If memory serves me right, Adrian Steinmann wrote: > > > It seems that as of Feb 27th the > > src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml file > > contains tags which causes make release on the RELENG_4_5 > > branch to fail because that tag is not defined. > > Support for was removed, for reasons that are too long to go into > here (the discussion is in the doc@ archive). > > As a work around, you can try building your release like this: > > make release RELEASETAG=RELENG_4_5 DOCRELEASETAG=RELEASE_4_5_0 ... ... > It'd be nice if this "just worked", but I'm opposed to messing around > with the release documentation on the security fix branches just to fix > this. I agree with this. Do you have any suggestions on where we could document the fact that building older release notes with a newer doc tree may not work? I'm mostly interested in preventing any hair-pulling this could result in. In this case, the failure mode is pretty obvious, but that may not always be the case. Worse yet, it might just produce incorrect output instead of failing to compile. [For those on -doc listening in: The general problem is that any infrastructure changes to the doc/ tree that aren't backwards-compatible might cause the release notes in the release branches to break.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message