Один из способов определить ваше управление версиями - придать семантическое значение каждой части:

• Переходите с N.x на N + 1.0, когда совместимость нарушается с новой версией
• Переходите от N.M к N.M + 1, когда добавляются новые функции, не нарушающие совместимость
• Переходите от N.M.X к N.M.X + 1, когда добавляются исправления ошибок.

Вышеупомянутое - всего лишь пример - вы хотите определить правила, которые имеют для вас смысл. Но пользователям очень приятно быстро определить, ожидается ли несовместимость, просто взглянув на версию.

О, и не забудьте опубликовать правила, которые вы придумываете, чтобы люди знали, чего ожидать.

Первое, что я бы порекомендовал, - это ознакомиться с различиями между версией сборки и версией файла. К сожалению, .NET имеет тенденцию рассматривать их как то же самое, когда дело доходит до файлов AssemblyInfo, поскольку обычно ставит только AssemblyVersion и позволяет FileVersion по умолчанию использовать то же значение.

Поскольку вы сказали, что это общая сборка, я предполагаю, что вы имеете в виду, что она используется на двоичном уровне (не путем включения проекта в различные решения). Если это так, вы хотите быть очень осторожными при изменении версии сборки, поскольку это то, что .NET использует для строгого имени сборки (чтобы вы могли поместить ее в GAC), а также составляет «полное имя сборки». Когда версия сборки изменяется, она может иметь критические изменения для приложений, которые ее используют, без добавления записей перенаправления сборки в файл app.config.

Что касается именования, я думаю, это зависит от правил именования вашей компании (если таковые имеются) и цели библиотеки. Например, если эта библиотека обеспечивает «базовую» (или системную) функциональность, которая не является специфической для какого-либо конкретного продукта или направления бизнеса, вы можете назвать ее следующим образом:

CompanyName.Framework.Core 

если это часть более крупной библиотеки, или просто

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

Что касается того, когда увеличивать номера версий, это все еще довольно субъективно и зависит от того, что вы считаете каждой частью номера сборки для представления. Схема Microsoft по умолчанию - Major.Minor.Build.Revision, но это не значит, что вы не можете придумать свои собственные определения. Самая важная вещь - быть последовательной в своей стратегии и убедиться, что определения и правила имеют смысл для всех ваших продуктов.

Почти во всех схемах версий, которые я видел, первые две части - Major.Minor. Основной номер версии обычно увеличивается, когда есть большие изменения и / или критические изменения, в то время как дополнительный номер версии обычно увеличивается, чтобы указать, что что-то измененное, которое произошло, не было критическим изменением. Два других числа значительно более субъективны и могут быть «сборкой» (которая часто является значением серийной даты или последовательно обновляемым номером, который меняется каждый день) и «ревизией» или номером патча. Я также видел их перевернутыми (давая Major.Minor.Revision.Build), где build - это последовательно увеличивающееся число из автоматизированной системы сборки.

Помните, что основная и дополнительная версии сборки используются в качестве номера версии библиотеки типов при экспорте сборки.

Наконец, взгляните на некоторые из этих ресурсов для получения дополнительной информации:

http://msdn.microsoft.com/en-us/library/51ket42z.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx

Некоторая полезная информация из эта статья в блоге Сюзанны Кук на MSDN (опубликовано 30 мая 2003 г.):

When to Change File/Assembly Versions

First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.

Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.

But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.

Shipping Builds
As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.

When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.

В семантическом управлении версиями есть набор руководящих принципов и правил относительно того, как это применять (и когда). Очень просто следовать, и это просто работает.

http://semver.org/