Процесс планирования выпусков

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

Различные виды выпусков

Различные виды выпусков содержат различные виды изменений. Это, в свою очередь, означает, что планирование выпуска различается для разных типов выпусков.

Выпуски исправлений

Выпуски исправлений изменяют только часть версии, относящуюся к исправлениям. Например, EF Core 3.1.1 — это выпуск, исправляющий проблемы, обнаруженные в EF Core 3.1.0.

Выпуски исправлений предназначены для устранения ошибок, являющихся критическими для клиентов. Это означает, что выпуски исправлений не содержат новые функции. Изменения API запрещено включать в состав выпусков исправлений, за исключением особых случаев.

Требования для внесения изменений в выпуске исправлений очень высоки. Это связано с тем критически важным условием, что выпуски исправлений не должны вносить новые ошибки. Таким образом, процесс принятия решений ориентирован на обеспечение значимого результата и низкого риска.

Мы с большей вероятностью займемся исправлением проблемы, если:

• она затрагивает нескольких клиентов;
• она унаследована от предыдущего выпуска;
• она приводит к повреждению данных.

Мы с меньшей вероятностью займемся исправлением проблемы, если:

• существуют разумные способы ее обхода;
• исправление с большой вероятностью вызовет другие нарушения в работе;
• ошибка появляется при отклонении от нормальных условий работы.

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

Окончательное решение о том, следует ли исправлять ошибку, принимают директоры .NET в Майкрософт.

Основные выпуски

Основные выпуски изменяют основной номер версии EF. Например, EF Core 3.0.0 — это основной выпуск, который представляет собой большой шаг вперед по сравнению с EF Core 2.2.x.

Основные выпуски:

• предназначены для улучшения качества и возможностей предыдущего выпуска;
• Как правило, содержат исправления ошибок и новые функции
  • Некоторые из новых функций могут представлять собой фундаментальные изменения в работе EF Core.
• Как правило, включают преднамеренные критические изменения
  • Критические изменения необходимы для развития EF Core по мере того, как мы получаем новые сведения.
  • Однако мы очень тщательно обдумываем внесение любых критических изменений из-за потенциального негативного воздействия на клиентов. В прошлом мы могли чрезмерно увлекаться критическими изменениями. В будущем мы будем стараться минимизировать изменения, способные нарушить работу приложений, а также сократить число изменений, нарушающих работу расширений и поставщиков баз данных.
• имеют множество предварительных выпусков, отправленных в NuGet.

Планирование для основных и дополнительных выпусков

Отслеживание вопросов на GitHub

GitHub (https://github.com/dotnet/efcore) — это источник истинных данных для всех планов EF Core.

Вопросы на GitHub имеют следующее:

• Состояние
  • Открытые вопросы не были решены.
  • Закрытые вопросы были решены.
    • Все вопросы, которые были решены, помечены тегом closed-fixed. Вопрос, помеченный тегом closed-fixed, решен и объединен, но, возможно, еще не выпущен.
    • Другие теги closed- указывают на другие причины для закрытия вопроса. Например, дубликаты помечаются тегом closed-duplicate.
• Тип
  • Bugs — это ошибки.
  • Enhancements — это новые функции или улучшения существующих функций.
• Веха
  • Вопросы без вехи находятся на рассмотрении у команды. Решение о том, что делать с этим вопросом, еще не принято, либо рассматривается возможность изменения принятого решения.
  • Проблемы в вехе невыполненной работы — это элементы, над которыми команда EF рассмотрит возможность работы в будущем выпуске.
    • Вопросы в невыполненной работе могут быть помечены тегом consider-for-next-release, указывающим, что этот рабочий элемент находится в начале списка задач для следующего выпуска.
  • Открытые вопросы в вехе с управлением версиями — это элементы, над которыми команда планирует работать в данной версии. Например, это вопросы, над которыми планируется работать для EF Core 5.0.
  • Закрытые вопросы в вехе с управлением версиями — это элементы, работа над которыми завершена для данной версии. Обратите внимание, что данная версия, возможно, еще не была выпущена. Например, это вопросы, работа над которыми завершена для EF Core 3.0.
• Голоса
  • Голосование — это лучший способ сообщить, что некий вопрос важен для вас.
  • Чтобы проголосовать, просто поставьте "палец вверх" 👍 для этого вопроса. Например, вот вопросы с наибольшим числом голосов.
  • Также добавьте комментарий с описанием конкретных причин, по которым эта функция вам необходима, если вы считаете, что он окажется полезным. Комментарии "+1" и аналогичные не несут в себе никакой пользы.

Процесс планирования

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

• сведениях от клиентов;
• сведениях от других заинтересованных лиц;
• выбранной стратегии;
• доступных ресурсах.
• Расписание

Некоторые из задаваемых нами вопросов:

1. Сколько разработчиков, по нашему мнению, будет использовать новую возможность, насколько она улучшит их приложения или облегчит процесс разработки? Чтобы ответить на этот вопрос, мы собираем отзывы из различных источников. Комментарии к запросам и голоса за них — один из таких источников. Взаимодействия с важными клиентами — другой.

2. Какие существуют обходные пути для использования этой возможности, пока мы ее не реализовали? Например, многие разработчики могут создать привязку таблицы объединения в качестве обходного пути, чтобы решить проблему отсутствия встроенной поддержки связей "многие ко многим". Очевидно, что не все разработчики станут это делать, но у многих есть такая возможность, и мы учитываем это при принятии решения.

3. Будет ли реализация этой возможности способствовать развитию EF Core, то есть приблизит ли это реализацию других возможностей? Мы стараемся отдавать предпочтение возможностям, которые становятся основой для других возможностей. Например, сущности с типом "контейнер свойств" могут помочь нам реализовать поддержку связей "многие ко многим", а конструкторы сущностей дали возможность реализовать поддержку отложенной загрузки.

4. Является ли возможность точкой расширяемости? Мы стараемся отдавать предпочтение точкам расширяемости вместо обычных возможностей, потому что они позволяют разработчикам подключать собственную функциональность и компенсировать отсутствие каких-либо функций.

5. Каков синергетический эффект от использования этой возможности в сочетании с другими продуктами? Мы отдаем предпочтение возможностям, которые добавляют или значительно улучшают взаимодействие EF Core с другими продуктами, например .NET Core, последней версией Visual Studio, Microsoft Azure и т. д.

6. Каковы навыки разработчиков, доступных для работы над этой возможностью, и как лучше всего распорядиться этими ресурсами? Каждый член команды EF и участники сообщества имеют разный уровень опыта в различных областях, и мы должны это учитывать. Даже если бы мы захотели бросить все силы на работу над конкретной возможностью, такой как преобразование оператора GroupBy или связи "многие ко многим", это было бы непрактично.