weekly update

_posts/mini_posts/2024-12-17-semver.md

@@ -0,0 +1,28 @@
+---
+layout: post
+title: Версионирование
+tags: [bestpractices, api]
+tg_id: 578
+---
+Де-факто стандарт для версионирования всяких библиотек и продуктов — [семантическое версионирование](https://semver.org/). Идеи довольно простые, хотя и полный документ содержит немного душноты.
+
+Браузеры со своими версиями за 300 и внутренние релизы некоторых компаний а-ля 0.192, годами крутящиеся на проде, передают пламенный привет:)
+
+Оказывается, у этого подхода есть куча критиков: [1](https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e), [2](https://thoughtspile.github.io/2021/11/08/semver-challenges/), [3](https://surfingthe.cloud/semantic-versioning-anti-pattern/).
+Недостатки сводятся к следующему:
+- Демагогия по поводу того, "а что такое ломающее изменение", "а если это влияет только на 1% пользователей", "а мелкое ли это изменение?", "это не баг, а фича" и т.п.
+- Не все следуют SemVer (sic!) (например, у них 0.x в проде).
+- О ужас, SemVer не всем подходит!
+- Одно число не может передать всей глубины изменений. На него нельзя полагаться при обновлениях, все равно надо читать список изменений.
+- Если ваш продукт последний в цепочке (например, фронтенд-морда) — о боже мой, всем насрать какой он там версии. Это все очень сложно, простоиспользуйте одно число, как например браузеры.
+- Частые обновления библиотек могут отпугнуть пользователей.
+- Настоящим инженерам вообще версии [не нужны](https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/) — посмотрите на ранние UNIX-программы, они совершенны! Версионирование — это отмазка, чтобы ломать API. 
+- В большом дереве зависимостей изменение одной версии может привести к каскадному ~~резонансу~~ изменению заметного числа зависимостей.
+- Инженеры боятся обновлять мажорную версию своей библиотеки, и откладывают внедрение фич. Иногда во имя маркетинга.
+- Ради обратной совместимости приходится делать костыли.
+
+На часть этих замечаний неплохо отвечает [создатель спецификации](https://tom.preston-werner.com/2022/05/23/major-version-numbers-are-not-sacred) (один из создателей GitHub кстати): не надо бояться увеличивать мажорную версию, не надо мешать маркетинг с техническими деталями, надо любить своих пользователей, предоставляя им средства для автоматических миграций, а ломающие изменения выдавать по чуть-чуть, а не огромными пачками.
+
+В java-мире сейчас обсуждают подход [Tip & Tail](https://openjdk.org/jeps/14), который может сгладить некоторые моменты (при этом не противореча идее SemVer). По сути предлагается иметь два релиза: tip, с новейшими фичами и всем таким, и tail, в котором все будет максимально стабильно и меняться очень редко и только когда прям совсем надо (по сути, LTS).
+
+

_posts/mini_posts/2024-12-19-markdown-link-copy.md

@@ -0,0 +1,15 @@
+---
+layout: post
+title: Дублирование ссылки в Markdown
+tags: [markdown]
+tg_id: 579
+---
+Понадобилось в во внутренней доке вынести часть ссылок в начало документа, чтобы не искать их в тексте. Оказывается, у Markdown есть механизм для ссылки на ссылку! В любом месте документа (например в конце) добавляем название
+```
+[link_name]: https://ov7a.narod.ru/index-1.html
+```
+И потом используем в квадратных скобках сколько угодно:
+```
+Это [ссылка][link_name]. И [это][link_name] та же самая ссылка.
+```
+