Bug 35620
| Summary: | make release fails in documentation for RELEASETAG=RELENG_4_5 as of Feb 28th | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Adrian Steinmann <ast> |
| Component: | Books & Articles | Assignee: | Murray Stokely <murray> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Adrian Steinmann
2002-03-07 07:20:01 UTC
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 <port> tags which causes make release on the RELENG_4_5
> branch to fail because that tag is not defined.
Support for <port> 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 ...
This will use a slightly older version of the doc/ tree that still
supports the <port> tag. This means that if you build the Handbook,
FAQ, or other FDP documents as a part of your release, they'll have the
older content as well.
FYI: Nobody updates the release notes on the security fix branches.
They remain frozen with the contents that they had at the time the
corresponding release was tagged. src/UPDATING contains patchlevel
information for security fix branches.
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.
Bruce.
"Bruce A. Mah" <bmah@freebsd.org> 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 <port> tags which causes make release on the RELENG_4_5 > > branch to fail because that tag is not defined. > > Support for <port> 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.] State Changed From-To: open->analyzed I have added a note to the new 'BUGS' section of release(7). Thanks for bringing this to our attention. I will MFC the man page addition later this week. Responsible Changed From-To: freebsd-doc->murray I have added a note to the new 'BUGS' section of release(7). Thanks for bringing this to our attention. I will MFC the man page addition later this week. State Changed From-To: analyzed->closed The workaround has not been documented in both -CURRENT and -STABLE. Thanks for bringing this to our attention. |
