1 % \iffalse meta-comment
4 % The LaTeX3 Project and any individual authors listed elsewhere
7 % This file is part of the LaTeX base system.
8 % -------------------------------------------
10 % It may be distributed and/or modified under the
11 % conditions of the LaTeX Project Public License, either version 1.3c
12 % of this license or (at your option) any later version.
13 % The latest version of this license is in
14 % http://www.latex-project.org/lppl.txt
15 % and version 1.3c or later is part of all distributions of LaTeX
16 % version 2005/12/01 or later.
18 % This file has the LPPL maintenance status "maintained".
20 % The list of all files belonging to the LaTeX base distribution is
21 % given in the file `manifest.txt'. See also `legal.txt' for additional
24 % The list of derived (unpacked) files belonging to the distribution
25 % and covered by LPPL is defined by the unpacking scripts (with
26 % extension .ins) which are part of the distribution.
33 \ProvidesFile{latexrelease.dtx}
35 %<driver>\ProvidesFile{latexrelease.drv}
36 %<fixltx2e>\ProvidesPackage{fixltx2e}
37 %<fixltx2e> [2015/06/22 v2.0b fixes to LaTeX (obsolete)]
38 %<latexrelease>\ProvidesPackage{latexrelease}
41 % \ProvidesFile{latexrelease.dtx}
42 [2015/06/22 v1.0f LaTeX release emulation and tests]
46 \documentclass{ltxdoc}
47 \newcommand\Lopt[1]{\textsf{#1}}
49 \providecommand{\file}[1]{\texttt{#1}}
50 \providecommand{\MF}{\textsf{Metafont}}
51 \providecommand{\danger}{\marginpar[\hfill\protect\Huge!!]{\protect\Huge!!\hfill}}
53 \DocInput{latexrelease.dtx}
64 % \GetFileInfo{latexrelease.dtx}
66 % \title{The \Lpack{latexrelease} package\thanks{This file
67 % has version number \fileversion, last
68 % revised \filedate.}}
69 % \author{The \LaTeX3 Project}
71 % \MaintainedByLaTeXTeam{latex}
74 % \section{Introduction}
75 % Prior to the 2015 release of \LaTeX{}, essentially no changes had been
76 % made to the \LaTeX\ format code for some years, with all
77 % improvements being instead added to the package \Lpack{fixltx2e}.
79 % While this worked at a technical level it meant that you had to
80 % explicitly opt-in to bug fixes and improvements, and the vast
81 % majority of documents did not benefit.
83 % As described in \LaTeX\ News 22, a new policy is being implemented
84 % in which improvements will now be added to the format by default,
85 % and this \Lpack{latexrelease} package may be used to ensure
86 % stability where needed, either by making a new format use an older
87 % definition of some commands, or conversely may be used to supply the
88 % new definitions for use with an old format.
92 % \RequirePackage[2015/01/01]{latexrelease}
93 % \documentclass{article}
97 % After such a declaration the document will use definitions current
98 % in the January 2015 \LaTeX{}, whether the actual format being used is
99 % older, or newer than that date. In the former case a copy of
100 % |latexrelease.sty| would need to be made available for use with the
101 % older format. This may be used, for example, to share a document
102 % between co-workers using different \LaTeX\ releases, or to protect a
103 % document from being affected by system updates. As well as the
104 % definitions within the format itself, individual packages may use
105 % the commands defined here to adjust their definitions to the
106 % specified date as described below.
109 % The bulk of this package, after some initial setup and option
110 % handling consists of a series of |\IncludeInRelease| commands
111 % which have been extracted from the main source files of the \LaTeX\
112 % format. These contain the old and new versions of any commands with
113 % modified definitions.
115 % \section{Package Options}
117 % \item \emph{yyyy/mm/dd}
118 % The package accepts any \LaTeX\ format date as argument,%
119 % although dates in the future for which the current release of this
120 % package has no information will generate a warning.
123 % |current| This is the default behaviour, it does not change the
124 % effective date of the format but does ensure that the
125 % |\IncludeInRelease| command is defined.
128 % |latest| sets the effective date of the format to the release date
129 % of this file, so in an older format applies all patches currently
134 % \section{Release Specific Code}
136 % The |\IncludeInRelease| mechanism allows the kernel developer to
137 % associate code with a specific date to choose different versions of
138 % definitions depending on the date specified as an option to the
139 % \Lpack{latexrelease} package. Is also available for use by package
140 % authors (or even in a document if necessary).
144 % \noindent\DescribeMacro{\IncludeInRelease}
145 % \marg{code-date}^^A
146 % \oarg{format-date}%^^A
150 % |\EndIncludeInRelease|
152 % \begin{description}
154 % \item[\marg{code-date}] This date is associated with the \marg{code}
155 % argument and will be compared to the requested date in the option to
156 % the \Lpack{latexrelease}.
158 % \item[\oarg{format-date}] This optional argument can be used to
159 % specify a format date with the code in addition to the mandatory
160 % \marg{code-date} argument. This can be useful for package developers
161 % as described below.
163 % \item[\marg{label}] The \marg{label} argument is an identifier
164 % (string) that within a given package must be a unique label for each
165 % related set of optional definitions. Per package at most one code
166 % block from all the |\IncludeInRelease| declarations with the same
167 % label will be executed.
169 % \item[\marg{message}]
170 % The \marg{message} is an informative string that is used in
171 % messages. It has no other function.
174 % Any \TeX\ code after the |\IncludeInRelease| arguments
175 % up until the and the following |\EndIncludeInRelease|
177 % conditionally included depending on the date of the format as
182 % The |\IncludeInRelease| declarations with a given label should be in
183 % reverse chronological order in the file. The one chosen will depend
184 % on this order, the effective format version and the date options, as
187 % If your package \Lpack{mypackage} defines a |\widget| command but
188 % has one definition using the features available in the 2015 \LaTeX\
189 % release, and a different definition is required for older formats
192 % \IncludeInRelease{2015/01/01}{\widget}{Widget Definition}
193 % \def\widget{new version}%
194 % \EndIncludeInRelease
196 % \IncludeInRelease{0000/00/00}{\widget}{Widget Definition}
197 % \def\widget{old version}%
198 % \EndIncludeInRelease
201 % If a document using this package is used with a format with
202 % effective release date of 2015/01/01 or later the new code will be
203 % used, otherwise the old code will be used. Note the \emph{effective
204 % release date} might be the original \LaTeX\ release date as shown at
205 % the start of every \LaTeX\ job, or it may be set by the
206 % \Lpack{latexrelease} package, so for example a document author who
207 % wants to ensure the new version is used could use
209 % \RequirePackage[2015/01/01]{latexrelease}
210 % \documentclass{article}
211 % \usepackage{mypackage}
214 % If the document is used with a \LaTeX\ format from 2014 or before,
215 % then \Lpack{latexrelease} will not have been part of the original
216 % distribution, but it may be obtained from a later \LaTeX\ release or
217 % from CTAN and distributed with the document, it will make an older
218 % \LaTeX\ release act essentially like the 2015 release.
220 % \subsection{Intermediate Package Releases}
222 % The above example works well for testing against the latex format
223 % but is not always ideal for controlling code by the release date of
224 % the \emph{package}. Suppose \LaTeX\ is not updated but in March you
225 % update the \Lpack{mypackage} package and modify the definition of
226 % |\widget|. You could code the package as:
228 % \IncludeInRelease{2015/03/01}{\widget}{Widget Definition}
229 % \def\widget{even newer improved March version}%
230 % \EndIncludeInRelease
232 % \IncludeInRelease{2015/01/01}{\widget}{Widget Definition}
233 % \def\widget{new version}%
234 % \EndIncludeInRelease
236 % \IncludeInRelease{0000/00/00}{\widget}{Widget Definition}
237 % \def\widget{old version}%
238 % \EndIncludeInRelease
241 % This would work and allow a document author to choose a date such as
243 % \RequirePackage[2015/03/01]{latexrelease}
244 % \documentclass{article}
245 % \usepackage{mypackage}
248 % To use the latest version, however it would have disadvantage that
249 % until the next release of \LaTeX, by default, if the document does
250 % not use \Lpack{latexrelease} to specify a date, the new improved
251 % code will not be selected as the effective date will be 2015/01/01
252 % and so the first code block will be skipped.
254 % For this reason |\IncludeInRelease| has an optional argument that
255 % specifies an alternative date to use if a date option has not been
256 % specified to \Lpack{latexrelease}.
258 % \IncludeInRelease{2015/03/01}[2015/01/01]{\widget}{Widget Definition}
259 % \def\widget{even newer improved March version}%
260 % \EndIncludeInRelease
262 % \IncludeInRelease{2015/01/01}{\widget}{Widget Definition}
263 % \def\widget{new version}%
264 % \EndIncludeInRelease
266 % \IncludeInRelease{0000/00/00}{\widget}{Widget Definition}
267 % \def\widget{old version}%
268 % \EndIncludeInRelease
271 % Now, by default on a 2015/01/01 \LaTeX\ format, the first code block
272 % will compare the format date to the optional argument 2015/01/01
273 % and so will execute the \emph{even newer improved} version. The
274 % remaining blocks using the |\widget| label argument will all then be
277 % If on the other hand the document requests an explicit release date
278 % using \Lpack{latexrelease} then this date will be used to decide what
279 % code block to include.
281 % \subsection{Using \cs{IncludeInRelease} in Packages}
283 % If |\IncludeInRelease| is used within a package then all such
284 % conditional code needs to be within such declarations, e.g., it is
285 % not possible in the above example to have the ``current'' definition
286 % of |\widget| somewhere in the main code and only the two older
287 % definitions inside |\IncludeInRelease| declarations. If you would do
288 % this then one of those |\IncludeInRelease| declarations would be
289 % included overwriting the even newer code in the main part of the
290 % package. As a result your package may get fragmented over time with
291 % various |\IncludeInRelease| declarations sprinkled throughout your
292 % code or you have to interrupt the reading flow by putting those
293 % declarations together but not necessarily in the place where they
296 % To avoid this issue you can use the following coding
297 % strategy: place the current |\widget| definition in the main code
298 % where it correctly belongs.
301 % \def\widget {even newer improved March version}
302 % \def\@widget{newly added helper command no defined in older releases}
305 % Then, near the end of your package place
308 % \IncludeInRelease{2015/03/01}[2015/01/01]{\widget}{Widget Definition}
309 % \EndIncludeInRelease
311 % \IncludeInRelease{2015/01/01}{\widget}{Widget Definition}
312 % \def\widget{new version}%
313 % \let\@widget\@undefined % this doesn't exist in earlier releases
314 % \EndIncludeInRelease
316 % \IncludeInRelease{0000/00/00}{\widget}{Widget Definition}
317 % \def\widget{old version}%
318 % \EndIncludeInRelease
320 % This way the empty code block hides the other |\IncludeInRelease|
321 % declarations unless there is an explicit request with a date
322 % 2015/01/01 or earlier.
324 % Now if you make a further change to |\widget| in the future you
325 % simply copy the current definition into the empty block and add a new
326 % empty declaration with todays date and the current format date. This
327 % way your main code stays readable and the old versions accumulate at
328 % the end of the package.\footnote{Of course there may be some cases
329 % in which the old code has to be in a specific place within the
330 % package as other code depends on it (e.g., if you
331 % \texttt{\string\let} something to it). In that case you have to
332 % place the code variations in the right place in your package rather
333 % than accumulating them at the very end.}
335 % The only other ``extra effort'' necessary when using this approach
336 % is that it may be advisable to undo new definitions in the code
337 % block for the previous release, e.g., in the above example we
338 % undefined |\@widget| as that isn't available in the 2015/01/01
339 % release but was defined in the main code. If all your conditional
340 % code is within |\IncludeInRelease| declarations that wouldn't been
341 % necessary as the new code only gets defined if that release is
346 % As noted above, prior to the 2015 \LaTeX\ release updates to the
347 % \LaTeX\ kernel were not made in the format source files but were
348 % made available in the \Lpack{fixltx2e} package. That package is no
349 % longer needed but we generate a small package from this source
350 % that just makes a warning message but otherwise does nothing.
358 % \section{Implementation}
360 % We require at least a somewhat sane version of \LaTeXe{}. Earlier
361 % ones where really quite different from one another.
364 \NeedsTeXFormat{LaTeX2e}[1996/06/01]
369 % \begin{macro}{\IncludeInRelease}
370 % \begin{macro}{\EndIncludeInRelease}
376 % \changes{v1.0c}{2015/02/19}{Swap argument order}
379 \def\@IncludeInRelease#1[#2]{\@IncludeInRele@se{#1}}%
380 \let\requestedpatchdate\CurrentOption}
381 \DeclareOption{latest}{%
382 \let\requestedpatchdate\latexreleaseversion}
383 \DeclareOption{current}{%
384 \let\requestedpatchdate\fmtversion}
388 \ExecuteOptions{current}
389 \ProcessOptions\relax
392 % Sanity check options, it allows some non-legal dates but always
393 % ensures |requestedLaTeXdate| gets set to a number. Generate an
394 % error if there are any non digit tokens remaining after removing the
398 \edef\requestedLaTeXdate{\the\count@}%
400 \def\reserved@b#1\\{%
402 \ifx\reserved@b\@empty\else
403 \PackageError{latexrelease}%
404 {Unexpected option \requestedpatchdate}%
405 {The option must be of the form yyyy/mm/dd}%
407 \afterassignment\reserved@a
409 \@parse@version\expandafter0\requestedpatchdate//00\@nil\\
412 % less precautions needed for |\fmtversion|
414 \edef\currentLaTeXdate{%
415 \expandafter\@parse@version\fmtversion//00\@nil}
419 \ifnum\requestedLaTeXdate=\currentLaTeXdate
420 \PackageWarningNoLine{latexrelease}{%
421 Current format date selected, no patches applied.}
422 \expandafter\endinput
426 % A newer version of latexrelease should have been distributed with
429 \ifnum\currentLaTeXdate
430 >\expandafter\@parse@version\latexreleaseversion//00\@nil
431 \PackageWarningNoLine{latexrelease}{%
432 The current package is for an older LaTeX format:\MessageBreak
433 LaTeX \fmtversion\space\MessageBreak
434 Obtain a newer version of this package!}
435 \expandafter\endinput
438 % can't patch into the future, could make this an error
439 % but it has some uses to control package updates
442 \ifnum\requestedLaTeXdate
443 >\expandafter\@parse@version\latexreleaseversion//00\@nil
444 \PackageWarningNoLine{latexrelease}{%
445 The current package is for LaTeX \latexreleaseversion:\MessageBreak
446 It has no patches beyond that date\MessageBreak
447 There may be an updated version\MessageBreak
448 of this package available from CTAN}
449 \expandafter\endinput
453 % Update the format version to the requested date.
455 \let\fmtversion\requestedpatchdate
456 \let\currentLaTeXdate\requestedLaTeXdate
460 % \section{Individual Changes}
462 % The code for each change will be inserted at this point, extracted
463 % from the kernel source files.
471 % Generate a stub \Lpack{fixltx2e} package:
474 \NeedsTeXFormat{LaTeX2e}
475 \PackageWarningNoLine{fixltx2e}{%
476 fixltx2e is not required with releases after 2015\MessageBreak
477 All fixes are now in the LaTeX kernel.\MessageBreak
478 See the latexrelease package for details}