Смена прошивок и их влияние на визуализацию Опции

[dkapotov]

Добрый день коллеги.

Как-то так повелось, что практически все появляющиеся прошивки так или иначе ведут к тому, что после их установки необходимо руками исправлять несовместимости в визуализации, элементах управления и т.д. Все бы ничего, но это отнимает прилично времени и требует протоколировать сделанные изменения в разных проектах, на разных объектах. В проекте, содержащем в LM 300-500 объектов и чуть меньшее количество элементов интерфейса такая работа радости и вдохновения не приносит. Поэтому я вот что подумал. Может быть имеет смысл обновлять прошивки по принципу операционных систем? Например, версии 1.1, 1.2, 1.3 и т.д. имеют незначительные изменения и исправления багов, переход между ними не ведет к перенастройке внутри LM. А вот версии следующих поколений, отличающихся в номере на головную единицу требуют значительной перенастройке, исправлений и т.д. и переход на них с предыдущего поколения не может быть простым и гладким.
Когда пользователь в лице нас, инсталляторов, знает номер версии, соответственно он принимает решение, на каком объекте ему стоит обновляться, а на каком нет. В большинстве случаев на объектах сильной нужды в обновлении нет, надо только баги поправлять. И здесь система должна работать по принципу "не трогай технику, она не подведет".
У меня сейчас в эксплуатации не много объектов с лоджиками - всего три. Но это все коммерческие объекты, с количеством адресов более 300. Меня вполне бы устроила прошивка с исправлениями выявленных багов, новые функции там не особо-то и нужны. Но мы получаем прошивку с исправленными ошибками и новой визуализацией. И тут уж сто раз подумаешь надо ли обновляться...
Мне кажется, что оптимальным должен быть такой алгоритм выхода новых прошивок (визуализаций):
1. При каждом обновлении прошивок должен прилагаться протокол внесенных изменений.
2. Обновленные прошивки должны иметь номер версии, однозначно характеризующей степень внесенных изменений
3. Прошивки одной версии должны поддерживаться до полного исправления обнаруженных ошибок
4. Следует отделять исправление ошибок от новых возможностей, тогда легче будет производителю принимать решение о сроках введения этих новых возможностей в эксплуатацию.

[dkapotov]

Добрый день коллеги.

Как-то так повелось, что практически все появляющиеся прошивки так или иначе ведут к тому, что после их установки необходимо руками исправлять несовместимости в визуализации, элементах управления и т.д. Все бы ничего, но это отнимает прилично времени и требует протоколировать сделанные изменения в разных проектах, на разных объектах. В проекте, содержащем в LM 300-500 объектов и чуть меньшее количество элементов интерфейса такая работа радости и вдохновения не приносит. Поэтому я вот что подумал. Может быть имеет смысл обновлять прошивки по принципу операционных систем? Например, версии 1.1, 1.2, 1.3 и т.д. имеют незначительные изменения и исправления багов, переход между ними не ведет к перенастройке внутри LM. А вот версии следующих поколений, отличающихся в номере на головную единицу требуют значительной перенастройке, исправлений и т.д. и переход на них с предыдущего поколения не может быть простым и гладким.
Когда пользователь в лице нас, инсталляторов, знает номер версии, соответственно он принимает решение, на каком объекте ему стоит обновляться, а на каком нет. В большинстве случаев на объектах сильной нужды в обновлении нет, надо только баги поправлять. И здесь система должна работать по принципу "не трогай технику, она не подведет".
У меня сейчас в эксплуатации не много объектов с лоджиками - всего три. Но это все коммерческие объекты, с количеством адресов более 300. Меня вполне бы устроила прошивка с исправлениями выявленных багов, новые функции там не особо-то и нужны. Но мы получаем прошивку с исправленными ошибками и новой визуализацией. И тут уж сто раз подумаешь надо ли обновляться...
Мне кажется, что оптимальным должен быть такой алгоритм выхода новых прошивок (визуализаций):
1. При каждом обновлении прошивок должен прилагаться протокол внесенных изменений.
2. Обновленные прошивки должны иметь номер версии, однозначно характеризующей степень внесенных изменений
3. Прошивки одной версии должны поддерживаться до полного исправления обнаруженных ошибок
4. Следует отделять исправление ошибок от новых возможностей, тогда легче будет производителю принимать решение о сроках введения этих новых возможностей в эксплуатацию.

[Alferov]

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

На мой взгляд, на введенном объекте, где заказчик не требует никаких дополнительных фишек, не стоит обновлять прошивки где бы то ни было. Зачем создавать себе проблемы и искать себе бесплатную работу? )))

[dkapotov]

Я абсолютно согласен с такой позицией и хотел лишь сказать то, что если в прошивке "старого" поколения выявлен баг, его надо исправить. С течением времени прошивка этой версии должна избавиться от всех обнаруженных багов, а вот прошивка "нового" поколения должна содержать новые возможности (с новыми багами :-))). Сейчас все смешалось в одну кучу и в результате стоишь перед выбором: обновлять прошивку, чтобы недостатки устранить, или бросить ее нафиг как есть

[Arrow]

Дмитрий, я согласен с Alferov, автоматически обновлять прошивку на работающих объектах слишком рискованно. Тем более сейчас обновления ставятся через веб-интерфейс и на объект приезжать совсем не нужно.
По поводу исправления багов и новых фич. За последние полгода очень сильно изменена прошивка, практически переписано заново. Поэтому до последнего времени и ставили прошивки от июля 2012, и только тем кого они чем-то не устраивали давали беты под свой страх и риск. Сейчас практически завершена пользовательская визуализация, планируются некоторые изменения в админском интерфейсе, после чего зафризим версию, и дальше уже будут минорные исправления багов