Здравствуйте.
В процессе написания письма про alsa-utils-1.0.1 и sound-scripts
написалось также следующее, и IMCO это повод для отдельной темы.

Целью предложения является увеличение преемственности и
поддерживаемости дистрибутивов, уменьшение затрат на решение
вопросов несовместимости как при выпуске обновлений, так и при
эксплуатации.

---
(Глядя на общий баланс процесса тестирования/выпуска compact и
версий ПО в нем (linux-2.4.22/glibc-2.2/oo-1.0.3/mozilla-1.4), я
бы не гнался за alsa-1.0.1 и тем же xmms-1.2.8: без толку, а
грабель огрести можно.)

Но на будущее вопрос остается: ведь каждый такой форк по API -- 
это усложнение поддержки (добавление грани несовместимости), 
поэтому при удачном подходе к релиз-менеджменту и планированию 
выпусков _должно_ получаться:

	фиксировать в точке релиза максимально осмысленное
	количество изменений API в окрестности времени выпуска.

Возможно, имеет смысл набросать нечто вроде таймлайна -- без тех
time, которые не(точно)известны, но с теми точками 
несовместимости, которые _уже_ известны.  Как-то glibc-2.3, 
alsa-1.0.x API, builds with linux-2.6 kernel headers by default?,
etc.  С тем, чтобы иметь возможность сводить переходные точки --
ведь на практике люди, отвечающие за такие системные сдвиги, 
обычно не одни и те же -- слишком тяжелые задачи.

Из прошлых изменений схожего плана -- rpm3/4, kernel22/24, 
alsa05/09, initscripts/service.  Т.е.:

	таким же API является базовая инфраструктура вроде
	стартовых скриптов, политики упаковки пакетов perl, а не
	только сугубо upstream API changes.

---

Кто что скажет?

--- пример

Выпуски ALM2.0/ALJ2.0/Утёс-К достаточно совместимы, чтобы по ним
выпускались общие updates.  Понятно, что это снижает затраты на
выпуск и применение таковых.

Выпуски ALM2.2/ALJ2.2 различались по KDE (как минимум), что было
нивелировано путем выпуска update к ALM2.2.  Вариант, но не
лучший.

Выпуск ALJ2.1 оказался достаточно промежуточным (и "прилагающимся
к журналу"), чтобы смысла организовывать его долгосрочную
поддержку не было. [...]

Сейчас выйдет Compact 2.3.  Вопрос в том, насколько его удастся
унифицировать по обновлениям с Junior 2.3, буде таковой
действительно собирается; а также и с Master update,
необходимость которого очевидна и вроде уже и не обсуждается
(если он будет выпущен; до конца декабря '03 уже не случилось).

Изучая ftp://updates.altlinux.ru, на сейчас могу только сделать
вывод, что какие-либо обязательства по поддержке 2.3(beta)
отсутствуют; следовательно, этот якорь не держит.

--- вопрос

Итак, какая версия libalsa должна быть в следующих выпусках?

Меня как майнтейнера этот момент интересует крайне сильно -- от
него зависит резервирование времени.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/