Сообщение Re: Obsolete от 28.10.2018 20:03
Изменено 28.10.2018 20:05 Qbit86
Re: Obsolete
Здравствуйте, Shmj, Вы писали:
S>Если имя поля в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно?
Если поле приватное (а оно таким и должно быть), то на пользователя не повлияет. Если под «полем» имелся в виду какой-то публичный член, то менять можно поэтапно. Сначала добавить корректный дубликат, а на старый повесить атрибут [Obsolete]. Через какое-то время удалить старый неправильный API с поднятием мажорной версии. У пользователя всё ещё будет опция продолжать использовать старую версию пакета.
S>А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес :(
Если пользователь обновляет библиотеку, у которой изменилась мажорная цифра, то он должен быть готов, что будут ломающие изменения — если следовать SemVer 2.0.0. Матюки оправданы только в том случае, если ломающие изменения введены с инкрементом лишь в минорной версии.
S>Если имя поля в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно?
Если поле приватное (а оно таким и должно быть), то на пользователя не повлияет. Если под «полем» имелся в виду какой-то публичный член, то менять можно поэтапно. Сначала добавить корректный дубликат, а на старый повесить атрибут [Obsolete]. Через какое-то время удалить старый неправильный API с поднятием мажорной версии. У пользователя всё ещё будет опция продолжать использовать старую версию пакета.
S>А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес :(
Если пользователь обновляет библиотеку, у которой изменилась мажорная цифра, то он должен быть готов, что будут ломающие изменения — если следовать SemVer 2.0.0. Матюки оправданы только в том случае, если ломающие изменения введены с инкрементом лишь в минорной версии.
Re: Obsolete
Здравствуйте, Shmj, Вы писали:
S>Если имя поля в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно?
Если поле приватное (а оно таким и должно быть), то на пользователя не повлияет. Если под «полем» имелся в виду какой-то публичный член, то менять можно поэтапно. Сначала добавить корректный дубликат, а на старый повесить атрибут [Obsolete]. Через какое-то время удалить старый неправильный API с поднятием мажорной версии. У пользователя всё ещё будет опция продолжать использовать старую версию пакета.
S>А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес :(
Если пользователь обновляет библиотеку, у которой изменилась мажорная цифра, то он должен быть готов, что будут ломающие изменения — согласно SemVer 2.0.0. Матюки оправданы только в том случае, если ломающие изменения введены с инкрементом лишь в минорной версии.
Неявно как-то «автоматически» пользовательская библиотека мажорную версию зависимости не апдейтнет.
S>Если имя поля в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно?
Если поле приватное (а оно таким и должно быть), то на пользователя не повлияет. Если под «полем» имелся в виду какой-то публичный член, то менять можно поэтапно. Сначала добавить корректный дубликат, а на старый повесить атрибут [Obsolete]. Через какое-то время удалить старый неправильный API с поднятием мажорной версии. У пользователя всё ещё будет опция продолжать использовать старую версию пакета.
S>А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес :(
Если пользователь обновляет библиотеку, у которой изменилась мажорная цифра, то он должен быть готов, что будут ломающие изменения — согласно SemVer 2.0.0. Матюки оправданы только в том случае, если ломающие изменения введены с инкрементом лишь в минорной версии.
Неявно как-то «автоматически» пользовательская библиотека мажорную версию зависимости не апдейтнет.