История изменений

Можешь попробовать выкатить концепцию пакетного менеджера с управлением зависимостями, не использующего номера версий. Удобного, универсального. Прямо сюда, коротенько.

Важнее не то какая версия у пакета, а то какие «фичи» внутри. Если бы все писалось в парадигме «делает только одно дело и делает его хорошо» то это все не нужно было бы, мы бы говорили «apt install libgit2-commit_v1 libgit2-merge_v2 libgit2-log_v3». Но так как у нас все это запихано внутрь одной кодовой базы и развивается как такой «роллинг-релиз» это не взлетит просто так, нужно менять подход к написанию софта. Использовать что-то типа сабмодулей гита. При этом изменение интерфейса фичи должно вести к изменению ее «названия», а «номера версий» фич используются для отметок при рефакторинге и исправлении багов (и это не обязательно монотонно изменяющиеся число, можно что угодно использовать лишь бы позволяло понять то же самое у тебя сейчас установлено или нет). Тогда бы мы могли брать пакеты с тем набором фич, который нам нужен, обновляли бы только то что нужно, могли бы всегда брать последние версии зная что обратная совместимость гарантирована и меньше бы конфликтов зависимостей было бы. То, как разработка ведется сейчас, такой подход не поддерживает, исключение разве что веб с версионированием API.

А, ну и пакетный менеджер соответственно не просто версию пакета бы сравнивал а смотрел что внутри. Условно такой requirements.txt из питона, только представляем что это у нас не проект с кучей либ в зависимостях а пакет с кучей фич в «зависимостях»

Можешь попробовать выкатить концепцию пакетного менеджера с управлением зависимостями, не использующего номера версий. Удобного, универсального. Прямо сюда, коротенько.

Важнее не то какая версия у пакета, а то какие «фичи» внутри. Если бы все писалось в парадигме «делает только одно дело и делает его хорошо» то это все не нужно было бы, мы бы говорили «apt install libgit2-commit_v1 libgit2-merge_v2 libgit2-log_v3». Но так как у нас все это запихано внутрь одной кодовой базы и развивается как такой «роллинг-релиз» это не взлетит просто так, нужно менять подход к написанию софта. Использовать что-то типа сабмодулей гита. При этом изменение интерфейса фичи должно вести к изменению ее «названия», а «номера версий» фич используются для отметок при рефакторинге и исправлении багов (и это не обязательно монотонно изменяющиеся число, можно что угодно использовать лишь бы позволяло понять то же самое у тебя сейчас установлено или нет). Тогда бы мы могли брать пакеты с тем набором фич, который нам нужен, обновляли бы только то что нужно, могли бы всегда брать последние версии зная что обратная совместимость гарантирована и меньше бы конфликтов зависимостей было бы. То, как разработка ведется сейчас, такой подход не поддерживает, исключение разве что веб с версионированием API.