N
+
Size: a a a
2020 November 26
S
тут копипаста в течении трех месяцев
да, достаточно было бы написать «пофиксили баги», кмк
M
мы просто хотим пирожков
E
Если в рамках минорных изменений, это не критично
E
А апдейты по закрытию дыр по безопасности вообще не всегда пишут)
AK
На одном из прошлых рабочих мест я как-то видел коммит с комментарием "minor refactorings and bugfixes", затрагивающий около тысячи файлов, из них около 200 содержали значимые изменения (разные), а не только рефакторинг. И все это в проекте sdk, от которого зависит все вообще. Сразу в мастер, в пятницу вечером
AK
Так, чет вспомнилось
M
Я считаю плохой практикой делать такой changelist для приложений в сторах. Что думает публика?
согласен вызывает легкую ненависть
SS
И в проектах которые веду требую чтобы changelist заполнялся
расскажи, как делаете? как отследить, что поменялось, что важно для пользователей, когда об этом рассказывать, если A/B тест, а если тест не удался - пишете, что убрали из приложения?
N
расскажи, как делаете? как отследить, что поменялось, что важно для пользователей, когда об этом рассказывать, если A/B тест, а если тест не удался - пишете, что убрали из приложения?
Да, писать то, что поменялось в UI, то, что могут потрогать.
SS
и вдогонку сразу вопрос как это скейлить, если у вас 200 команд над приложением работает? 🤷🏻♂️
N
Есть эпики и юзер стори, которые закрываются в результате работы команд, есть релиз менеджер который может из них написать пару строк.
N
никто же не требует писать документацию для каждого релиза
SS
а как часто у вас релизы, кстати?
SS
мне правда интересно, я не критикую
N
В зависимости от проектов от двух недель до месяцев
N
Так я ищу критику) зачем ещё писать сюда
AC
Я на прошлом проекте сделал требование, чтобы каждый PR содержал внятный текст в чейнжлоге, через какое-то время разработчики стали сами во время ревью на это внимание обращать
SS
а на все языки переводите, или один?
IV
когда 200 команд хз как делать, но для всех остального писать changelog в начале, на этапе планирования работ