Если не обновлять модули некоторое время, то может накопится несколько версий. И при обновлении они устанавливаются все сразу. Дать возможность устанавливать каждую версию по отдельности.
В настройках главного модуля возможно установить Автоматически проверять наличие обновлений:
- Не проверять
- Каждый день
- Раз в неделю
- Раз в месяц
Предоставить настройку (галочку или поле для указания email), которые активируют функцию отправки о доступных обновлениях после проверки.
- Не проверять
- Каждый день
- Раз в неделю
- Раз в месяц
Предоставить настройку (галочку или поле для указания email), которые активируют функцию отправки о доступных обновлениях после проверки.
- Было бы здорово иметь возможность просматривать ченжлог для новых версий модулей не кликая по обновлениям для каждого модуля, а списком на общей странице.
- Также хотелось бы иметь более развернутую информацию по исправлениям вместо "Исправлены незначительные ошибки" и "добавлены незначительные улучшения".
- Также хотелось бы иметь более развернутую информацию по исправлениям вместо "Исправлены незначительные ошибки" и "добавлены незначительные улучшения".
В связи с полным интеграционным тестированием обновлений Битрикс на тестовом окружении, которое может занимать несколько дней, к моменту обновления рабочего сайта через site_update релизные версии модлей уже могу отличаться от установленных на тесте.
Поэтому возникает ситуация, что тест приходится обновлять несколько раз, несколько раз прогонять все функциональные тесты и потом надеяться, что к моменту обновления рабочего сайта новых апдейтов не выйдет.
Поэтому возникает ситуация, что тест приходится обновлять несколько раз, несколько раз прогонять все функциональные тесты и потом надеяться, что к моменту обновления рабочего сайта новых апдейтов не выйдет.
Не хватает возможности выбирать до какой версии обновлять платформу и модули.
Для чего это надо? Типовой сценарий: прежде чем обновлять бой, надо обновить тестовую копию и тщательно её тестировать. К сожалению, так называемые стабильные обновления битрикса вовсе таковыми не являются, а пользователи битрикса - это армия бесплатных тестеров. Поэтому тщательное тестирование обновлений может занять некоторое время, потому что после обновлений иногда обнаруживается необходимость доработок и т.д. Пока проходит тестирование и наступает готовность обновить бой, выпускаются новые "стабильне" обновления битрикса с исправленными ошибками предыдущего "стабильного" обновления
, а обновить бой только до проверенных версий обновлений возможности нет, приходится снова обновлять тест и снова проверять.
Наличие возможности выбирать для платформы и для каждого модуля, версию до которой надо обновиться позволило бы устанавливать только действительно стабильные проверенные обновления.
Для чего это надо? Типовой сценарий: прежде чем обновлять бой, надо обновить тестовую копию и тщательно её тестировать. К сожалению, так называемые стабильные обновления битрикса вовсе таковыми не являются, а пользователи битрикса - это армия бесплатных тестеров. Поэтому тщательное тестирование обновлений может занять некоторое время, потому что после обновлений иногда обнаруживается необходимость доработок и т.д. Пока проходит тестирование и наступает готовность обновить бой, выпускаются новые "стабильне" обновления битрикса с исправленными ошибками предыдущего "стабильного" обновления
, а обновить бой только до проверенных версий обновлений возможности нет, приходится снова обновлять тест и снова проверять.Наличие возможности выбирать для платформы и для каждого модуля, версию до которой надо обновиться позволило бы устанавливать только действительно стабильные проверенные обновления.
Когда загружаешь последнюю версию своего модуля, нельзя проверить его работоспособность.
У меня неймспейс в файле сломал скрипт, который выдал обсфукатор. И ты никак не можешь это проверить не выложив модуль в общий доступ.
Считай все пользователи могут скачать не работающее решение и написать на тебя жалобу)
Нужно, чтобы после загрузки архива с модулем он не сразу становился активным, а только после того, как ты нажал кнопку "Активировать", а до этого момента ты можешь его загружать, скачивать обсфуцированный к себе сколь угодно. В это время будет раздаваться предыдущая версия модуля.
Также предлагаю выводить историю загрузок.
v0.5 - 22.01.2015 21:25 - (увидел, что косяк откатился назад)
v1 - 22.01.2015 21:23
v0.5 - 10.05.2013 21:23
v0.4 - 25.01.2012 22:48
v0.1 - 22.01.2012 22:48
У меня неймспейс в файле сломал скрипт, который выдал обсфукатор. И ты никак не можешь это проверить не выложив модуль в общий доступ.
Считай все пользователи могут скачать не работающее решение и написать на тебя жалобу)
Нужно, чтобы после загрузки архива с модулем он не сразу становился активным, а только после того, как ты нажал кнопку "Активировать", а до этого момента ты можешь его загружать, скачивать обсфуцированный к себе сколь угодно. В это время будет раздаваться предыдущая версия модуля.
Также предлагаю выводить историю загрузок.
v0.5 - 22.01.2015 21:25 - (увидел, что косяк откатился назад)
v1 - 22.01.2015 21:23
v0.5 - 10.05.2013 21:23
v0.4 - 25.01.2012 22:48
v0.1 - 22.01.2012 22:48
Проблема
Необходимо поддерживать на разных площадках (дев, тест, демо, бой) проекта одинаковые версии Битрикса, в т. ч. установленных в нём модулей. Копирование бекапа сайта не подходит, т. к.:
Необходимо в Битриксе реализовать АПИ, которое будет позволять выборочно обновлять модули до указанной версии. Концептуальный пример (передаём код модуля и версию, до которой нужно обновиться):
После полного обновления системы на одной из площадок можно будет с помощью события OnUpdatesInstalled сгенерировать файл с зафиксированными версиями установленных модулей. Этот файл размещается в VCS проекта и распространяется по всем площадкам. Далее остаётся написать нехитрый скрипт, который будет выполнять обновление модулей до зафиксированных версий, используя АПИ из примера выше.
---
Всё это можно реализовать самостоятельно, от Битрикса нужно только АПИ для установки обновлений конкретной версии.
Необходимо поддерживать на разных площадках (дев, тест, демо, бой) проекта одинаковые версии Битрикса, в т. ч. установленных в нём модулей. Копирование бекапа сайта не подходит, т. к.:
- «Накатывать» обновления нужно в автоматическом режиме на протяжении всего ЖЦ проекта.
- Данные, хранимые в БД, частично могут различаться на площадках.
Необходимо в Битриксе реализовать АПИ, которое будет позволять выборочно обновлять модули до указанной версии. Концептуальный пример (передаём код модуля и версию, до которой нужно обновиться):
SystemUpdate::updateModule($module, $version); |
После полного обновления системы на одной из площадок можно будет с помощью события OnUpdatesInstalled сгенерировать файл с зафиксированными версиями установленных модулей. Этот файл размещается в VCS проекта и распространяется по всем площадкам. Далее остаётся написать нехитрый скрипт, который будет выполнять обновление модулей до зафиксированных версий, используя АПИ из примера выше.
---
Всё это можно реализовать самостоятельно, от Битрикса нужно только АПИ для установки обновлений конкретной версии.
Возникает неудобства при планирование обновление битрикс, когда версия протестирована и в момент обновления публичной версии выясняется, что вышла новая версия. Хотелось бы, что бы такие вещи были более прогнозируемы.
В списке обновлений, вместе с версией модуля, хотелось бы видеть дату.
Сегодня столкнулся с неприятной ситуацией, когда после очередного "стабильного" обновления перестал работать код:
Как оказалось, теперь поле FORUM_ID не является допустимым для использования в фильтре, однако в документации это не отражено, в результате чего пришлось изучать исходный код в поисках причины пропавшей работоспособности.
Ранее об этом уже упоминалось, но хочется еще раз поднять вопрос о том, что бы для обновлений был максимально подробный changelog, что бы было понятно заранее к чему готовится. Кроме этого, я бы предпочел, и думаю, что я не один такой буду, кто был бы готов подождать обновлений, но зато что все изменения были задокументированы.
$res = CTasks::GetList(
Array("ID" => "ASC"),
Array(
"RESPONSIBLE_ID" => $userId,
"FORUM_ID" => $forumId
)
);
|
Ранее об этом уже упоминалось, но хочется еще раз поднять вопрос о том, что бы для обновлений был максимально подробный changelog, что бы было понятно заранее к чему готовится. Кроме этого, я бы предпочел, и думаю, что я не один такой буду, кто был бы готов подождать обновлений, но зато что все изменения были задокументированы.
Пример:
Замечательно функционировал информационный портал с разделом "блоги". После планового обновления bitrix, обновился и модуль blogs. В результате пользователи получили новый крайне не удобный интерфейс и отказываются писать новые сообщения. Хотелось бы иметь возможность откатить обновление конкретного модуля до предыдущей версии, чтобы оперативно решать подобные проблемы.
Замечательно функционировал информационный портал с разделом "блоги". После планового обновления bitrix, обновился и модуль blogs. В результате пользователи получили новый крайне не удобный интерфейс и отказываются писать новые сообщения. Хотелось бы иметь возможность откатить обновление конкретного модуля до предыдущей версии, чтобы оперативно решать подобные проблемы.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Разработчики откладывают написание доки до появления реально стабильной работы своих модулей.