Если имя свойства/метода в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно? А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес

На другой чаше — стремление к перфекционизму, стремление исправлять ошибки.

Исправлять или нет?

Здравствуйте, Shmj, Вы писали:

S>Если имя поля в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно? А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес

S>На другой чаше — стремление к перфекционизму, стремление исправлять ошибки.

S>Исправлять или нет?

Обычно решается добавлением нового с объявлением старого ObsoleteAttribute.
Потом когда-нибудь в будущем старое поле убирается.
Ломающие изменения обязательно сопровождаются сменой мажорной версии.

Здравствуйте, Shmj, Вы писали:

S>Если имя поля в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно?

Если поле приватное (а оно таким и должно быть), то на пользователя не повлияет. Если под «полем» имелся в виду какой-то публичный член, то менять можно поэтапно. Сначала добавить корректный дубликат, а на старый повесить атрибут [Obsolete]. Через какое-то время удалить старый неправильный API с поднятием мажорной версии. У пользователя всё ещё будет опция продолжать использовать старую версию пакета.

S>А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес :(

Если пользователь обновляет библиотеку, у которой изменилась мажорная цифра, то он должен быть готов, что будут ломающие изменения — согласно SemVer 2.0.0. Матюки оправданы только в том случае, если ломающие изменения введены с инкрементом лишь в минорной версии.

Неявно как-то «автоматически» пользовательская библиотека мажорную версию зависимости не апдейтнет.

Здравствуйте, Shmj, Вы писали:

S>Если имя свойства/метода в старой версии подобрано не удачно
S>Исправлять или нет?

Я б исправил. Даже если это широчайше используемая либа (не ваш случай ), программеру не составит труда посмотреть deprecated описание и вставить новый метод. Зато десятки других новых юзеров либы не будут материться, почему в поле ДатаСоздания лежит стоимость заказа.

Здравствуйте, Shmj, Вы писали:

S>Если имя свойства/метода в старой версии подобрано не удачно или написано с ошибкой — стоит ли менять? На функционал не повлияет же, верно? А пользователю геммор, т.к. при обновлении версии через NuGet — проект перестанет собираться и тысячи матюков будут отправлены в ваш адрес

S>На другой чаше — стремление к перфекционизму, стремление исправлять ошибки.

S>Исправлять или нет?

1. В следующей мажорной версии помечаешь все старое как Obsolete и добавляешь новые правильные кошерные методы.
2. В следующей через один мажорной версии убираешь все старье.
Ессна же между выпусками мажорных версий должно пройти не менее пары месяцев(в зависимости от кол-ва пользователей библиотеки и их распределенности).