Почему Microsoft не разветвляет C #, .NET, CLR для серьезных изменений (горизонтальное управление версиями)?

Question

Это не похоже на новые версии, где более новые версии будут иметь обратную совместимость.

Что я имею в виду, когда разработчики C #, .NET, CLR осознают, что допустили ошибку или упустили из виду нечто, что могло бы принести огромную пользу, но теперь они не смогли добиться этого из-за обратной совместимости, они могли Разветвите соответствующий продукт, скажем, как, обозначив его по-другому (горизонтальное управление версиями).

Разве это не было бы более перспективным?

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

Таким образом, вы бы сказали, что используете C # 4.0, тогда есть кое-что очень полезное, что вы можете использовать из C # 4.0 B1 (ветвь 1) и просто использовать это, даже если это может потребовать некоторых усилий по переносу.

Разве это не здоровая стратегия развития, когда новые проекты всегда могут начать использовать самую последнюю и самую лучшую, то есть самую последнюю версию и последнюю ветвь определенного языка (например, C # 6.0 B4)?

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

Каковы потенциальные плюсы / минусы этой стратегии развития?

Answer 1

Огромное преимущество имеет наличие большого набора библиотек, доступных для платформы. В настоящее время, если я пишу приложение .NET 4.0, я могу ссылаться на библиотеки, которые были созданы еще в .NET 1.1. Это означает, что есть много существующего кода, которым я могу воспользоваться, и это один из главных преимуществ .NET.

Если я правильно понимаю ваше предложение, то если библиотека A написана для C # 4.0B1, а библиотека B написана для C # 4.0B2, то мое приложение не может быть написано так, чтобы ссылаться как на библиотеку A, так и на библиотеку B. Это привело бы к фрагментации платформы и усложнило бы оправдание инвестиций в написание приложений или библиотек на C #.

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

Answer 2

У многих (более крупных) магазинов достаточно проблем, чтобы не отставать от основных версий .Net, которые уже выходят.Эта стратегия могла бы работать для платформы, которая не является доминирующей платформой разработки во всем мире, но для Microsoft (и многих разработчиков) это было бы адом.

Обратная совместимость очень серьезно воспринимается в Microsoft, особенно там, где разработчики (жизненная сила)компании, так как Windows взлетела в середине 90-х) обеспокоены.Глубокие изменения оказывают непостижимое влияние из-за масштаба Windows, а в последствии .Net, принятия.Хотели бы вы быть тем парнем, который должен был объяснить Стиву Баллмеру, почему ваше крутое исправление в новой минорной версии .Net сломало приложения, с которыми GE (скажем) управляет своим бизнесом?Прилагаются огромные усилия для того, чтобы старые приложения и устройства продолжали работать.Увеличение матрицы тестируемых версий неизбежно приведет к срезанию углов, и мы все знаем, что будет дальше, верно?

Вы можете утверждать, что никто не должен принимать последние версии.Но кто здесь не устанавливает Windows SP, как только они выходят, чтобы избежать проблем с безопасностью?Существует естественная склонность к желанию последних, хотя это должно быть сбалансировано с проблемами стабильности.

.Net стал хорошим способом удаления ада DLL из лексикона разработчика Windows и в некоторой степени отделил платформу разработчикапрогресс от выпусков ОС.Я не думаю, что большинство разработчиков Windows спешат увидеть это изменение.Любите их или ненавидите их, Microsoft очень хорошо справляется с крупными, нечастыми выпусками того, что по-прежнему является мировым стандартом de facto для настольных ПК.Будет интересно посмотреть, как Google справится с той же проблемой, поскольку Android займет это место на рынке мобильных устройств в течение следующего года или двух.

Answer 3

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

К счастью, единственный случай, когда это получит какую-либо поддержку в сообществе, это когда мы либовзяли его на роль специалиста (чтобы он на самом деле не конкурировал с оригинальным проектом, просто основывался на общем предке), или там, где было огромное недовольство тем, как был запущен оригинальный проект (где это своего рода ядерный ударопция в политике открытого исходного кода).

Причина, по которой он использовался как аргумент чудовищ против открытого исходного кода, заключается в том, что было бы просто невозможно отследить, какая версия какой версии какой версии какой версии данногобиблиотека, фреймворк, язык, компонент и т. д. может работать с какой версией какой версии какой версии какой версии другой.

К счастью, открытые или закрытые, такие ветви могут умереть естественной смертью на глазах«рынка» (был ли этот рынокатомарный или другой).