Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, ·, Вы писали:
P>>>У нас внутри экосистемы подобные механизмы документированы и поддерживаются всеми клиентам. Консумер или берет такой клиент, или пилит свой с учетом конвеншна. P>·>Ты так и не обосновал, зачем это пихать в каждый ответ. Чем это принципиально отличается от простой публикации changelog консьюмерам. P>changelog содержит мизерное количество информации — название, ссылка на тикет, подробности, каменты, пул-реквест и тд. Отсюда далеко не всегда ясно, каким именно будет поведение конкретной системы. Соответсвенно, придется 1. прогнать тесты для всех n-систем/сервисов 2. надеяться, что в тестах будет прокрыта именно та самая ветка(и тут надо вспомнить, что не существует таких гарантий).
В changelog в любом случае можно поместить несравненно больше информации, чем в хедер.
P>Т.е. все равно придется подкрутить мониторинг, что бы он хоть как то детектил проблемы, на случай п.2 А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и
Это всё средства.
P>дает знать команде соответсвующего сервиса, что у них чтото там не то.
А вот и цель. Так чем это принципиально отличается от емейла?
P>·>Я ещё понимаю, если посылать номер версии в хедере "Server" или каком-нибудь "X-My-API-Version". Так консумеры могут догадаться, что с v1.2.3 работало, а с v1.2.4 что-то вдруг подглючивать стало, значит стоит поподробнее changelog почитать. Но что делать с Warning? P>Например, мониторинг может подсказать, что после передеплоймента какого то из сервисов часть клиенты начали получать варнинги, и это стоит проверить.
Уже поздно. Хотя... если придерживаться принципа "лучше поздно, чем никогда"... то может и ок. Но это как последняя линия обороны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай