(sec-changelog)= # Changelog Every **resolved issue** of Exudyn, newest first, with the version it produced. The micro version *is* the count of closed issues, so each line below is one version number: 1.10.160 is the 160th issue closed in release 1.10. An issue that was closed without being resolved is in no list: it changed nothing - which is why a release can span more version numbers than it has lines here. Every entry carries the **type** of the issue, then its **priority** and its **effort** as badges (`LOW EFF` is within 2 hours, `MEDIUM EFF` is within 16 hours, `HIGH EFF` is within 40 hours, `HUGE EFF` is above 40 hours), then who raised it and who resolved it - both omitted when that was Johannes Gerstmayr (JG). This file is generated; it is written by the tracker whenever an issue closes. **Only the current release is below.** The issues resolved before it, in the same form, are in the {ref}`issue tracker ` of the documentation, which also lists the open issues and the known bugs; the table that follows is the whole history at a glance. | release | name | resolved issues | highest version | |---|---|---|---| | 1.13 | Newborn | 7 | 1.13.6 | | 1.12 | Metheney | 367 | 1.12.462 | | 1.11 | McLaughlin | 240 | 1.11.240 | | 1.10 | Lagrene | 160 | 1.10.160 | | 1.9 | Krall | 235 | 1.9.234 | | 1.8 | Jones | 82 | 1.8.81 | | 1.7 | Hall | 124 | 1.7.123 | | 1.6 | Gillespie | 188 | 1.6.189 | | 1.5 | Fitzgerald | 118 | 1.5.118 | | 1.4 | Ellington | 66 | 1.4.65 | | 1.3 | Davis | 106 | 1.3.105 | | 1.2 | Corea | 147 | 1.2.146 | | 1.1 | Burton | 178 | 1.1.177 | | 1.0 | Abercrombie | 290 | 1.0.295 | | 0.1 | - | 359 | 0.1.367 | ## Version 1.13 - Newborn (current) - **1.13.6** `TESTING` `HIGH` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` allExudynModulesTest fails where Python has no tkinter: the Windows jobs of GitHub CI (#2920) - description: GitHub CI of 1.13.5, windows-2025, cp313 (Python 3.13.12, the interpreter cibuildwheel installs for its tests): 'Failed to execute ...exudyn/misc/GUI.py: No module named tkinter', so the model returns 0 and --exit-code fails all Windows wheel jobs; the other 15 jobs passed. tkinter is optional for Exudyn - only the dialogs need it, and every other module imports GUI.py lazily - **notes:** allExudynModulesTest skips GUI.py where Python has no tkinter, which only the dialogs need; the Windows jobs of GitHub CI pass again. revision2026b step RG10.27 - date resolved: **2026-10-09 20:38**, date raised: 2026-10-09 - **1.13.5** `TESTING` `HIGH` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` the GitHub macOS test jobs fail on two platform differences, and Linux ARM has no list (#2919) - description: GitHub CI of 1.13.3, macos-15 ARM: geometricallyExactBeamRightAngleFrame (rel. 3.9e-10, cp313 and cp314) and objectFFRFreducedOrderTest (rel. 1.3e-08, cp314 only) differ beyond the tolerance and are not in UnresolvedOnMacOS, so --exit-code fails the job. Linux ARM (aarch64) was judged with UnresolvedOnLinux although it is arm64 and fuses a\*b+c into FMA as macOS ARM does - **notes:** the test suite on macOS ARM accepts two more known platform differences (geometricallyExactBeamRightAngleFrame, objectFFRFreducedOrderTest on cp314), and Linux ARM is judged with the same list. revision2026b step RG10.26 - date resolved: **2026-10-09 19:43**, date raised: 2026-10-09 - **1.13.4** `BUG` `HIGH` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` the Linux ARM wheels do not build: exudynCPPfast gets the x86-64 options -mavx2 -mfma (#2918) - description: GitHub CI of 1.13.3, ubuntu-24.04-arm: g++: error: unrecognized command-line option '-mavx2' / '-mfma' while compiling exudynCPPfast. A release version builds the fast module for every Python version and setup.py adds the AVX2 options on every Linux; a development version builds it only on cp313, so the ARM jobs of dev builds failed the same way there. \_\_init\_\_.py loads exudynCPPfast only on a CPU with AVX2, so on ARM it is never used - **notes:** the Linux ARM wheels build again: setup.py builds exudynCPPfast, with its AVX2 options, only on x86-64 Linux; on ARM it was never loaded. revision2026b step RG10.26 - date resolved: **2026-10-09 19:43**, date raised: 2026-10-09 - **1.13.3** `DOCU` `HIGH` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` the GitHub start page and the PyPI page show stale texts with a dead link to theDoc.pdf (#2917) - description: GitHub shows README.md before README.rst: a 22-line leftover (RST syntax in a .md file, Python 3.6 - 3.9, docs/theDoc/theDoc.pdf), while README.rst is the landing page of Read the Docs. The PyPI description, inline in pyproject.toml, also pointed to theDoc.pdf; it is part of the wheel metadata, so the 1.13.2 wheels cannot be published with it (maintainer 2026-10-09, after pushing master) - **notes:** GitHub shows README.rst, the landing page of Read the Docs (the stale README.md is removed); the PyPI description links to the documentation on Read the Docs instead of the deleted theDoc.pdf. revision2026b step RG3.44 - date resolved: **2026-10-09 17:08**, date raised: 2026-10-09 - **1.13.2** `BUG` `NORMAL` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` exudev points to an empty setuppy.output.txt when a test fails (#2913) - description: after any failing build or release step exudev printed 'compiler output: setuppy.output.txt' - also when a test suite failed and the file was empty or from an earlier build; it now names the file only if this run wrote something into it - **notes:** exudev names setuppy.output.txt after a failed build or release only if this run wrote something into it. revision2026b step RG10.25 - date resolved: **2026-10-09 13:04**, date raised: 2026-10-09 - **1.13.1** `TESTING` `HIGH` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` the AVX2 reference set is stale - 26 test models and 4 mini examples fail under exudynCPPfast (#2912) - description: AVX2ReferenceSolutionUpdate (recorded 2026-09-17) was not renewed when the regular reference values moved (modified Newton default \#2815 and others), so the fast-module suite of the 1.13 release failed on 3.10 and 3.13; re-recorded from the fast logs of cp310 and cp313, which agree to the last digit - **notes:** the AVX2 reference set re-recorded from the fast-module suite on cp310 and cp313 (identical); contactFrictionCircleCable2DnoFrictionTest takes 1000 steps, so Newton converges and both modules agree; the mini example ObjectConnectorRigidBodySpringDamper has one value for both modules; runPerformanceTests.py applies the AVX2 set to its single runs. revision2026b step RG2.7 - date resolved: **2026-10-09 13:04**, date raised: 2026-10-09 - **1.13.0** `TESTING` `HIGH` `LOW EFF` `raised by: Claude-JG` `resolved by: Claude-JG` test models that count refused input fail under exudynCPPfast (#2911) - description: the fast-module suite of the 1.13 release: createItemNumbersTest raised (the Create functions skip the item-kind checks in exudynCPPfast, so a node reaches AddMarker and raises ExudynTypeError instead of ValueError), homogeneousTransformationInterfaceTest counted 3 must-raise cases that raise nothing there, ANCFThinPlateRevisionTest failed testInvalidIntegrationModeRaises; these cases are judged only in the regular module, as symbolicModuleTest does ('\[FAST\]' in exu.config.Version(True)) - **notes:** createItemNumbersTest, homogeneousTransformationInterfaceTest and ANCFThinPlateRevisionTest judge refused input only in the regular module; exudynCPPfast skips these checks by design. revision2026b step RG2.7 - date resolved: **2026-10-09 13:04**, date raised: 2026-10-09