|
04.10.2018, 21:11 | #1 |
Участник
|
|
|
04.10.2018, 21:36 | #2 |
Banned
|
Спасибо. Удивительно как быстро я отстал от жизни.
Добавление параметра по умолчанию - breaking change. Cкорее всего из-за Chain of command. То есть ради того чтобы у других были связаны руки, они связали себе ноги. Цитата:
Adding or removing a default method parameter on a protected or public method – Consumers might have wrapped or subscribed to the method.
|
|
05.10.2018, 10:05 | #3 |
Moderator
|
|
|
05.10.2018, 10:12 | #4 |
Banned
|
Наверняка по запросу клиента. Мы вот тоже до десятка запросов послали сделать тот или иной расширяемым. Кому дать приоритет? Непонятно. С точки зрения бизнеса - тем, кто просят расширить, поскольку увеличивает клиентсткую базу.
|
|
05.10.2018, 11:49 | #5 |
Участник
|
Вы немного перекручиваете. Еще с первой версии документации про енумы было написано: "не используйте > или <, а то сделают его расширяемым и все развалится" Ребята, которые возмущались, ее не читали и у них таки развалилось, но они решили винить МС. Хотя МС пока заявляет о совместимости на уровне компиляции, а не на уровне логики, потому как предсказать извращенность некоторых расширений дано только высшему разуму.
Последний раз редактировалось skuull; 05.10.2018 в 13:28. |
|
|
За это сообщение автора поблагодарили: EVGL (1), ax_mct (1). |
05.10.2018, 12:42 | #6 |
Moderator
|
Цитата:
Сообщение от skuull
Вы немного перекручиваете. Еще с первой версии документации про енумы было написано: "не используйте > или <, а то сделают его расширяемым и все развалиться" Ребята, которые возмущались, ее не читали и у них таки развалилось, но они решили винить МС. Хотя МС пока заявляет о совместимости на уровне компиляции, а не на уровне логики, потому как предсказать извращенность некоторых расширений дано только высшему разуму.
Вообще - на мой взгляд, то что сейчас с этой continuous update происходит - это классический пример сочетания технооптимизма (верой в то что магическая новая технология обновлений может решить нерешаемую проблему) и явно выраженной проблеммы коммуникаций внутри корпорации (рядовые ПМ вполне себе понимают что все это - полная херня, но чтобы не создавать себе проблем - тупо ждут негативного фидбека от клиентов или первого громного скандала с гигантскими клиенсткими убытками по итогам обновления...) |
|
05.10.2018, 13:12 | #7 |
Banned
|
Цитата:
Цитата:
Сообщение от fed
Я не перекручиваю. Я просто вижу конфликт между задекларированным (правда в не очень ясной форме) отсутствием breaking changes и явной необходимостью заполнения дыр в функционале (которые теперь партнеры не могут сами затыкать). У меня в целом ощущение, что Микрософт чуть позже пойдет на попятную и по поводу отсутствия breaking changes в новых версиях и по поводу обязательности обновлений каждый месяц.
Вообще - на мой взгляд, то что сейчас с этой continuous update происходит - это классический пример сочетания технооптимизма (верой в то что магическая новая технология обновлений может решить нерешаемую проблему) и явно выраженной проблеммы коммуникаций внутри корпорации (рядовые ПМ вполне себе понимают что все это - полная херня, но чтобы не создавать себе проблем - тупо ждут негативного фидбека от клиентов или первого громного скандала с гигантскими клиенсткими убытками по итогам обновления...) Остаюсь технопессимистом. Перефразируя http://ifreestore.net/4790/2/ Техноопессимизм -мировоззренческая позиция, система взглядов, в соответствии с которыми погоня за технологиями рассматривается в качестве главной причины нарушения баланса в отношениях бизнеса и вендора, появления и резкого обострения проблем развития системы. |
|
05.10.2018, 13:38 | #8 |
Moderator
|
ну я скорее говорю о пробелах в функциональности, которые были в DAX2012 и благополучно остались в D365FO. Например - более или менее сложная и расширяемая себестоимость сопродуктов, более или менее жизнеспособная незавершенка (и не только в Российской локализации) и тд и тп. И если до закрытия overlayering партнеры могли как-то это допиливать на проектах, то в extensions model все более или менее существенные изменения могут быть сделаны только MS.
|
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
05.10.2018, 13:08 | #9 |
Moderator
|
Цитата:
Сообщение от skuull
Вы немного перекручиваете. Еще с первой версии документации про енумы было написано: "не используйте > или <, а то сделают его расширяемым и все развалиться" Ребята, которые возмущались, ее не читали и у них таки развалилось, но они решили винить МС. Хотя МС пока заявляет о совместимости на уровне компиляции, а не на уровне логики, потому как предсказать извращенность некоторых расширений дано только высшему разуму.
|
|
05.10.2018, 13:35 | #10 |
Участник
|
Цитата:
Сообщение от fed
Кстати - с формальной точки зрения, там в этой дискуссии кто-то привел ссылку на микрософтовский документ, которая описывает переделку из enum в extensuble enum как breaking change. Что микрософт, вроде бы, обещал не делать после выхода версии 8.0 Вот мне и интересно - у них концепция изменилась или они просто ошиблись ? Ну то есть - я вполне могу согласиться с тем, что партнер не очень корректно закодил. Вопрос в том, что микрософт нарушил (или не нарушил ???) ими же самими задекларированные условия.
Вы еще вспомните internalUseAttribute он в PU20 всем все поломал, раньше был ворнинг но всем было всеравно, а щас вот ошибка компиляции, breaking это по вашему? |
|
05.10.2018, 13:45 | #11 |
Moderator
|
Цитата:
Сообщение от skuull
С формальной точки зрения высказывания на ямере эквивалентны высказыванимя тут, с docs таже беда, сегодня там одно написано, завтра - другое. Я думаю нет ниодного документа в котором было бы что-то написано, а то засудят еще
Вы еще вспомните internalUseAttribute он в PU20 всем все поломал, раньше был ворнинг но всем было всеравно, а щас вот ошибка компиляции, breaking это по вашему? Плюс рано или поздно, у какого-то клиента не хватит ресурсов на то чтобы очередной ежемесячный багфикс потестить и у него весь бизнес встанет недельки на три-четыре. Я конечно понимаю что лицензионные соглашения MS позволяют ему выйти сухим из воды. Но вот выхлоп на рынок (Типа - фирма XYZ Productions с внедрением на 1000 рабочих мест простояла месяц с убытками в 800 лямов) может быть достаточно неприятным. А прессрелизы о том что "Да они сами виноваты - толком не тестировали", могут навести потенциальных клиентов на неприятную мысль что им теперь раз в месяц придется ключевых сотрудников отрывать от бизнеса и все тестировать. А это очень хороший sales point для конкурентов, и очень плохой для партнеров MS. |
|
05.10.2018, 15:13 | #12 |
Banned
|
Цитата:
При этом выбирают ту систему в которой все уже подходит изначально. Что интересно некий опрос говорит о том что 70% бизнеса не важно облако или нет, им важнее функциональность. То есть заполненность дыр на первом месте. https://softwareconnect.com/mrp/buye...s-2018-report/ Цитата:
Manufacturers claim to be very flexible in how they are willing to deploy MRP software, with nearly three-quarters (71 percent) indicating they would be open to reviewing either hosted or on-site installation options.
Кстати по поводу D365FO и крупного бизнеса. Размер базы данных. Как то выглядит все непросто в облаке. https://docs.microsoft.com/en-us/azu...ngle-databases P.S. Ну и немного жизнерадостности Есть такие фотки у команды MS? Хочется посмотреть им в лицо Последний раз редактировалось ax_mct; 05.10.2018 в 15:16. |
|
|
За это сообщение автора поблагодарили: belugin (0). |
05.10.2018, 19:15 | #13 |
Участник
|
Цитата:
т.е. допустим тебе надо добавить параметр в метод, добавить просто так нельзя, это breaking changes, но можно сделать следующее: добавляешь к этому методу атрибут SysObsolete, делаешь новый метод-копию с нужными тебе параметрами, правишь везде вызовы на твой новый метод. Профит сейчас при обновлении на 8.1 вылезно несколько таких штук Несовместимые обновления кстати никто не обещал выпускать, обещали без breaking changes Последний раз редактировалось trud; 05.10.2018 в 19:18. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
Теги |
ax7, dyn365fo, dynamics 365 for operations |
|
|