Какие стратегии существуют для управления обновлениями нескольких подпродуктов и нескольких выпусков?

Question

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

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

Все это кажется утомительным как во время разработки, так и во время выпуска — и подвержено ошибкам.Какие-либо предложения?

Answer 1

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

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

На основе этой информации вы можете реализовать решения об изменении версии.