chore: mention removal of ruamel.yaml.cglib pinning

Relate to #1536

[skip ci]

Author: php-coder

docs/decisions-log.md

@@ -6,7 +6,7 @@
 | 22.01.2022 Workaround | [php-coder/mystamps#1549](https://github.com/php-coder/mystamps/issues/1549): During update of **Liquibase** from 4.5.0 to 4.7.1 a new issue has been popped up: starting from 4.7.1 it logs all applied migrations to the console. And it seems like it logs directly and it doesn't respect logger configuration. It has a low impact to production but in test environment it spams a lot as we always apply all existing migrations. Moreover, it also affects unit tests where we use in-memory database. I raised this question in upstream (see my comments in [liquibase/liquibase#2200](https://github.com/liquibase/liquibase/pull/1932#discussion_r790117453)) but it might be an issue on our side as we use the latest Liquibase and (very old) Spring Boot 2.1.18 Commits: [f3c2e20d](https://github.com/php-coder/mystamps/commit/f3c2e20d1ba78703f53b6b090bfe7f7257e34a04)<br />UPDATE(24.01.2022): Bug: [liquibase/liquibase#2396](https://github.com/liquibase/liquibase/issues/2396) |
 | 10.11.2021 Workaround | [php-coder/mystamps#1549](https://github.com/php-coder/mystamps/issues/1549): During update of **Liquibase** from 4.5.0 to 4.6.1 the bug has been faced -- the migration `0.4/2017-05-29--test_image.xml` has started to fail with error `BLOB resource not found: /test/test.png`. I postponed this update and filled a bug report to upstream. Bug: [liquibase/liquibase#2200](https://github.com/liquibase/liquibase/issues/2200)<br />UPDATE(22.01.2022): in [f3c2e20d](https://github.com/php-coder/mystamps/commit/f3c2e20d1ba78703f53b6b090bfe7f7257e34a04) I have updated Liquibase to the latest version and also I applied a workaround by specifying a relative path instead of an absolute one. The future of the bug report isn't clear at this moment: it's definitely broke the backward compatibility and even a workaround requires us to modify the existing migration (that we mustn't do! but we can as this particular migration is used only by tests). From another hand, this change was made intentionally and it might stay with us forever |
 | 02.07.2021 Workaround | Enablement of `GuardLogStatement` in **PMD** led to a few false positives when we concatenate constant string literals. This should be fixed in PMD >= 6.36.0 but until we have this version (see [php-coder/mystamps#1250](https://github.com/php-coder/mystamps/issues/1250)), I suppressed violations manually. Bug: [pmd/pmd#957](https://github.com/pmd/pmd/issues/957) Commits: [0b135cb4](https://github.com/php-coder/mystamps/commit/0b135cb41f2da6d5ffc6570acf0ae68db35295f7) |
-| 02.07.2021 Workaround | [php-coder/mystamps#1536](https://github.com/php-coder/mystamps/issues/1536): `pip install robotframework-lint` has started to fail in TravisCI because one of the transitive dependencies (**robotframework-lint** -> robotframework -> ruamel.yaml.clib 0.2.4) requires at least Python 3.5 In order to unbreak the builds, I pinned the version of `robotframework` but it wasn't enough. Then I pinned the version of **ruamel.yaml.clib** to the latest worked version 0.2.2 Commits: [6c0180cb](https://github.com/php-coder/mystamps/commit/6c0180cb8c90df0d8239b123094ac7d9dd7d29f0), [8447ddb2](https://github.com/php-coder/mystamps/commit/8447ddb2f4944906a97619c9964afff3e2ff7842), [e6186331](https://github.com/php-coder/mystamps/commit/e61863319fdef76417f0e1a31b430aad10226748) |
+| 02.07.2021 Workaround | ~~[php-coder/mystamps#1536](https://github.com/php-coder/mystamps/issues/1536): `pip install robotframework-lint` has started to fail in TravisCI because one of the transitive dependencies (**robotframework-lint** -> robotframework -> ruamel.yaml.clib 0.2.4) requires at least **Python** 3.5 In order to unbreak the builds, I pinned the version of `robotframework` but it wasn't enough. Then I pinned the version of **ruamel.yaml.clib** to the latest worked version 0.2.2 Commits: [6c0180cb](https://github.com/php-coder/mystamps/commit/6c0180cb8c90df0d8239b123094ac7d9dd7d29f0), [8447ddb2](https://github.com/php-coder/mystamps/commit/8447ddb2f4944906a97619c9964afff3e2ff7842), [e6186331](https://github.com/php-coder/mystamps/commit/e61863319fdef76417f0e1a31b430aad10226748)~~<br/>UPDATE(10.07.2022): since [0e09fac8](https://github.com/php-coder/mystamps/commit/0e09fac8663d6642e13c7c413d550da163d4fa95) we have Python 3.6 installed and this workaround is no longer needed. I removed it in [bae944a](https://github.com/php-coder/mystamps/commit/bae944ac077d2827e61c85967c69d51ac532c266) |
 | 09.01.2021 Decision | [php-coder/mystamps#1495](https://github.com/php-coder/mystamps/issues/1495): Let's move **generated images** for the diagrams to the separate branch (`generated-assets`). Later we can apply this approach for other generated content (reports, for example). Pros: it reduces a disk space/repository size because we always hold only the latest version of the images. We will use force-push for rewriting data. Cons: it makes diagram update (especially with PRs) a little more complex because it requires 2 commits (PRs). Commits: [6e7e149f](https://github.com/php-coder/mystamps/commit/6e7e149f84756a6fd817dc23e6e80c145783c784) |
 | 20.06.2020 Decision | When I released 0.4 version after 5 years of development, I decided to [**make releases often**](https://en.wikipedia.org/wiki/Release_early,_release_often): every 3 months. In case when some planned issues haven't been implemented, they should be postponed to the next release and they shouldn't delay a release. Starting from 0.4.5 I've decided to make releases even more frequently -- *every 2 months*. This will improve our confidence that the release procedures are up-to-date. |
 | 20.06.2020 Decision | [php-coder/mystamps#1159](https://github.com/php-coder/mystamps/issues/1159): based on experience, most of time when I made a dependency update, I spent on reading a list of changes. This came especially notable with Spring Boot updates when reading might took 85-90% of time because I had to read also changelogs of Spring Framework, Spring Security and sometimes other libraries. As a consequence of this approach, at this moment, we use old and unsupported Spring Boot version (2.0.x) while the current one is 2.3.x Decision: in order to keep up with new releases, we should sacrify the pedancy and a full understanding of the changes that happen with our dependencies. **Reading of changelogs** should be an optional and if an update passed the integration tests, this is enough level of confidence. |