2

The last release broke one of the styles I rely on and reverting MiKTeX seems to be faster than fixing the style.

I asked this question as I was looking for a way to binary search through releases to find which one broke the style before reporting it to the style author, @andybuckley.

I considered

  1. Using the code stored under https://github.com/MiKTeX/miktex/releases/tag [as suggested by @AndréC] but found the overhead to install the complete MiKTeX toolchain to be too much. Plus, as pointed out by @david-carlisle, this only contains the code to build MiKTeX: the packages would still be pulled from the current versions.
  2. I also looked at the MiKTeX Docker images. They are also available for only the current release (AFAICT), but are cool nonetheless.
  3. LiveTeX does maintain a complete archive: e.g., ftp://tug.org/historic/systems/texlive/2018.

LiveTeX allowed me to determine that the break comes between the 2018 and 2019 releases. If anyone is interested, here is the MWE; 

\documentclass{minimal}
\usepackage{hepparticles} % the package under test
\newcommand{\Pg}{{\HepParticle{g}{}{}}} % gluon
\begin{document}
:\Pg:
\end{document}

Output under LiveTeX 2018: ":g:"; under LiveTeX 2019: "::"

The problem is also displayed when running the package test file, http://mirrors.ctan.org/macros/latex/contrib/hepparticles/testhepparticles.tex.

In the newer version, \updefault-> up, while previously it was \updefault -> n.

Found the origin: The default value of \updefault.

George
  • 23
  • 2
    Asking google seems to be faster! – Black Mild Feb 11 '20 at 15:09
  • 1
    Welcome to the site. While your question is a valid one, it might also be helpful to edit your question and indicate what broke with your style. There may be ready-made fixes for the issue. – Steven B. Segletes Feb 11 '20 at 15:17
  • The issue is rather unlikely to be caused by a change in miktx itself (TeX is rather stable) but more likely to be due to a change in some tex package that you are using, so you would not just need old binaries of the tex program but the entire old package distribution server from the previous version. – David Carlisle Feb 11 '20 at 19:20
  • Possible duplicate: Historical, stable version archive of packages – Werner Feb 11 '20 at 21:31
  • After edition. I run your MWE and the example from the link and both worked correctly (":g:" was produced and the whole example with tons of "B"s). I have MikTeX updated at 03 Feb 2020. Could you try to download the package from CTAN hepparticles (https://www.ctan.org/pkg/hepparticles) and paste it on the same folder of your main tex file? – FHZ Feb 12 '20 at 14:01
  • If the copy and paste works, then you may verify how to create your local package folder, something like explained here Create a local texmf tree in MiKTeX. – FHZ Feb 12 '20 at 14:03
  • I have just installed a fresh copy of MiKTeX from the repo and let it update: MiKTeX-pdfTeX 2.9.7338 (1.40.21) (MiKTeX 2.9.7300 64-bit). I then tried the MWE using the local copy of hepparticles, letting MiKTeX download it from CTAN, and copying a pasting a version from CTAN. None produced a 'g' (for gluon, by the way). TeXLive 2018 still works, however. – George Feb 12 '20 at 15:02
  • It is quite odd @George. When there is a file in the same folder of the main tex file, latex will give it priority over any other copy in the repository. You can edit the file hepparticles.sty to test if the file on the folder is to one being used. For example, edit at the command \DeclareRobustCommand{\HepParticle}[3], the line \@HepConStyle{{{#1}}{} to \@HepConStyle{{{A#1}}{}. The result should be :Ag:. hepparticles requires the packages subdepth and amsmath, and also OT1 fonts as stated on the line 110 of the .sty file. Sorry I can't give you better advices. – FHZ Feb 13 '20 at 00:31
  • I compile with pdflatex and latex->dvips->ps2pdf commands and both produced the correct result to me. I cannot replicate your issue at my machine. Btw, I'm on Windows. – FHZ Feb 13 '20 at 00:37
  • I am always concerned that something like this could occur, which is why I wanted pristine versions of TeX to test against. I have no idea how to proceed to fix this, but at least I can run against the older TeXLive version. Thank you so much for your help. If I figure it out, I will post the result. – George Feb 13 '20 at 12:48
  • PS: Using the latest MiKTeX Docker container [ce72f1275e1d, Version 3.14159265-2.6-1.40.20 (MiKTeX 2.9.6980)] returns PDF with the problem. Am I cursed? – George Feb 13 '20 at 15:06

2 Answers2

2

The MikTeX source is stored on github. As Git is a version control software, previous versions are kept and can be downloaded here : https://github.com/MiKTeX/miktex/tags

screenshot

AndréC
  • 24,137
  • 1
    this is sort of true but the OPs problem is almost certainly caused by a newer latex package rather then a newer miktex binary, so to get a working "old release" would need the entire server infrastructure for installing older packages on the demand from whichever time you were rolling back to. – David Carlisle Feb 11 '20 at 19:18
  • @DavidCarlisle You are certainly right, but obviously the OP remains deaf and dumb to these arguments similar to those of Steven B. Segletes. From now on, he will be able to verify by himself where is the true and false. – AndréC Feb 11 '20 at 19:22
0

Hi @George and welcome to TeX-SE.

Although you may still find the old releases of MikTeX MiKTeX Releases, you will quickly find out that the older versions are not avaliable anymore, e.g., MiKTeX 2.4 Status.

I would strongly recommend you to ask a more specific question about the problem you are dealing with. For example, which style, class, package, etc. is not working.

FHZ
  • 3,939