Если настройки будут храниться не в формате "как-левая-нога-захотела", а в чем-то более внятном и легко дополняемом, то поддерживать "обновлятор" будет не так уж трудно.
Например, если хранить настройки в ini-файле, то в чем трудность? Даже если в новый ini-файл был расширен и туда добавлены новые директивы, то не вижу сложности сопоставить два ini файла и получить результирующий на выходе.
Автоматическое обновление
Я попробую, потестим, а там уже решать админам, нужно или нет. Хотя, по себе скажу, что даже собрать установщик занимает время, посему админов понять можно.
Добавлено спустя 3 минуты 5 секунд:
Добавлено спустя 3 минуты 5 секунд:
Гарантий нет, по этому в данном случае нужно будет установщик изменять.Zord писал(а):А если при этом пропустить с десяток версий? Вы гарантируете, что "результирующий на выходе" будет нормальным?
Если данные структурированы, а не произвольной кучей валяются, которая меняется от версии к версии, то никаких проблем я не вижу.Zord писал(а):А если при этом пропустить с десяток версий? Вы гарантируете, что "результирующий на выходе" будет нормальным?
Между PHP 5.0 и PHP 5.5 вышел не один десяток версий. Попробуйте придумать ситуацию, при которой нельзя настройки из ini для 5.0 перенести в 5.5. Депрекейтед директивы при переносе комментятся, чтоб ошибок не вызывали, а остальные переносятся как есть. Новые (которых не было в 5.0 и появились позже) в результирующий ini-файл включаются с дефолтным значением.
Если уж совсем дружественным делать интерфейс, то можно предупреждать юзера о деприкейтед директивах и спрашивать, что с ними делать - переносить, как есть (на страх и совесть самого юзера), переносить в виде комментариев или вообще удалять.
В чем проблема-то?
Ну пусть их 10. Или 20. Проблема в количестве или в чем? Конкретно можете указать, с переносом конфигурации какого продукта будут проблемы?Zord писал(а):Проблема в том, что тут не один ini-файл...
Выше писал уже - если грамотно продумать конфигурационный файл, то эта проблема решаема. И формат ini, и формат xml вполне позволяют расширять их довольно гибко. Если будет, например, выбран формат ini, то хоть в каждой новой версии могут добавляться по 10 новых секций и по 100 новых директив, если сами директивы не будут произвольно переименовываться - какие тут могут быть проблемы?Zord писал(а):да и архитектура проекта не устоялась еще...
Используйте поиск, сколько можно-то?aVadim писал(а):Ну пусть их 10. Или 20. Проблема в количестве или в чем? Конкретно можете указать, с переносом конфигурации какого продукта будут проблемы?
Кто вам такое обещал?aVadim писал(а):если сами директивы не будут произвольно переименовываться - какие тут могут быть проблемы?
Ну, хотя бы ОДИН раз, наверное, ответить и можно, ответить КОНКРЕТНО и по существу, без лишнего бла-бла-бла. Разумеется, если есть, что ответитьZord писал(а):Используйте поиск, сколько можно-то?
А я говорил, что это кто-то обещал? Наоборот, я обозначал этот момент, как ключевую проблему - читайте мои комменты на предыдущей странице.Zord писал(а):Кто вам такое обещал?
Максим уже отвечал и не разaVadim писал(а):Ну, хотя бы ОДИН раз, наверное, ответить и можно, ответить КОНКРЕТНО и по существу, без лишнего бла-бла-бла. Разумеется, если есть, что ответить
Ну раз эта проблема не решена на данный момент, то чего вы хотите?aVadim писал(а):А я говорил, что это кто-то обещал? Наоборот, я обозначал этот момент, как ключевую проблему - читайте мои комменты на предыдущей странице.
Конкретно и по существу? Ни разу! Если я ошибаюсь, то дайте ссылку хотя бы на один ответ, где называлось бы, с переносом конфигурации какого КОНКРЕТНОГО продукта будут проблемыZord писал(а):Максим уже отвечал и не разaVadim писал(а):Ну, хотя бы ОДИН раз, наверное, ответить и можно, ответить КОНКРЕТНО и по существу, без лишнего бла-бла-бла. Разумеется, если есть, что ответить
Чуть выше уже писал, чего я хочу. Что-то непонятно?Zord писал(а):Ну раз эта проблема не решена на данный момент, то чего вы хотите?