LINUX.ORG.RU

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

Исправление x86_64, (текущая версия) :

А как должны были поступить разработчики правильного языка?

Прежде чем что-то вводить, как следует проработать.

Тащить этот .abs_sub() до скончания времён?

До 2.0 как минимум. Если хотят быть продакшеном то в 2.0 депрекейтнуть а в 3.0 выкинуть.

Спокойно глотать его вплоть до последнего минорного релиза ветки 1.*, а потом в 2.0 сразу выкинуть, типа раз уж взялись мигрировать на новый мажорный релиз, вот и поработайте?

Если ввели в 1.0 то глотать. Сами виноваты.

По-моему, если принято решение убрать некоторый метод, правильнее всего сообщить об этом как можно раньше (т.е. отменить устаревшим в минорном релизе), чтоб меньше кода от него зависело и удалить в мажорном релизе,

Это как минимум.

но не менее чем через N месяцев после отметки. Вроде как это и есть метод раста.

А вот не менее через N месяцев - это вообще не к чему.

Исходная версия x86_64, :

А как должны были поступить разработчики правильного языка?

Прежде чем что-то вводить, как следует проработать.

Тащить этот .abs_sub() до скончания времён?

До 2.0 как минимум. Если хотят быть продакшеном то в 2.0 депрекейтнуть а в 3.0 выкинуть.

Спокойно глотать его вплоть до последнего минорного релиза ветки 1.*, а потом в 2.0 сразу выкинуть, типа раз уж взялись мигрировать на новый мажорный релиз, вот и поработайте?

Если ввели в 1.0 то глотать. Сами виноваты.

По-моему, если принято решение убрать некоторый метод, правильнее всего сообщить об этом как можно раньше (т.е. отменить устаревшим в минорном релизе), чтоб меньше кода от него зависело и удалить в мажорном релизе,

Это как минимум.

но не менее чем через N месяцев после отметки. Вроде как это и есть метод раста.

А вот не менее через N месяцев - это вообще ни к чему.