Пользуясь случаем, напоминаю. Мы вам написали issue IDEA-64583, прошло два года, а сдвига все нет. Очень надеялись на 12 версию. Для нас актуальный тикет, т.к. пользуемся gerrit, amend там используется постоянно. 31 голос и 4 duplicate у этого тикета.
P.S. Спасибо вам за IDEA, PyCharm, TeamCity — превосходные продукты, пользуемся ими много лет, планируем апгрейд версии.
Что касается opensource-проектов, то они как правило завязаны очень жестким BC-контрактом, отсюда меньше пространства для рефакторинга, поэтому и изменения можно применять более постепенно.
А во внутренних проектах разработчики вольны делать все, до чего договорятся, а некоторые изменения просто не предполагают пошаговости — патчсет может быть очень большим, его ревью и доработки могут идти не один месяц. До окончания ревью мержить это крайне нежелательно. Согласен, когда идет параллельная разработка в trunk, его будет сложнее смержить, но для этого есть регулярный rebase. И, как верно заметил dborovikov, как откатить фичу полностью в случае чего?
Неразбериха с версиями происходит уже на этом этапе, поскольку одному и тому же артефакту теперь соответствуют две ревизии в VCS.
При этом Вы предлагаете отказаться от SNAPSHOT, либо я неправильно что-то понял. Разве это не породит неразбериху с версиями? Если уж так важно различать каждую сборку, то в maven 3 поведение по умолчанию так и есть — не может быть двух SNAPSHOT-артефактов одной версии, они должны различаться timestamp'ом.
У меня второй аккаунт (для тестов ВК-приложений) заблокировали еще месяца два-три назад — как раз с требованием указать номер телефона, которое нельзя было проигнорировать. Видимо, раньше это было как-то выборочно (низкая активность), сейчас — везде.
Да, в master. Если мержит один человек, проблемы нет. Мы используем gerrit, замержить может любой ревьюер после прохождения ревью.
Кстати, про git flow мы узнали не так давно — как раз при подготовке статьи, думаем его попробовать.
Если вся разработка ведется в одной ветке, в которую идут активные мержи (и разработчиков много), то состав релиза зависит от момента сборки. Если build-машина собирает на каждое обновление репозитория, то у нас может в итоге получиться много разных сборок «version 1.0».
Это подходит для варианта «nightly build», но не для major-релиза. Это имелось в виду.
Насчет «проще» — вещь индивидуальная. Нам так удобнее, я лишь предложил вариант.
Мы ушли от такого варианта, потому что нам приходилось делать копии конфигураций в TeamCity на каждый релизный бранч (компиляция, тесты, сборка пакета, в сумме 5-6 конфигов), к тому же если делать хотфикс в релизном бранче, есть шанс забыть сделать cherry-pick назад в master (лучше, конечно, как в вашем варианте — из master)
P.S. Спасибо вам за IDEA, PyCharm, TeamCity — превосходные продукты, пользуемся ими много лет, планируем апгрейд версии.
А во внутренних проектах разработчики вольны делать все, до чего договорятся, а некоторые изменения просто не предполагают пошаговости — патчсет может быть очень большим, его ревью и доработки могут идти не один месяц. До окончания ревью мержить это крайне нежелательно. Согласен, когда идет параллельная разработка в trunk, его будет сложнее смержить, но для этого есть регулярный rebase. И, как верно заметил dborovikov, как откатить фичу полностью в случае чего?
При этом Вы предлагаете отказаться от SNAPSHOT, либо я неправильно что-то понял. Разве это не породит неразбериху с версиями? Если уж так важно различать каждую сборку, то в maven 3 поведение по умолчанию так и есть — не может быть двух SNAPSHOT-артефактов одной версии, они должны различаться timestamp'ом.
Кстати, про git flow мы узнали не так давно — как раз при подготовке статьи, думаем его попробовать.
Это подходит для варианта «nightly build», но не для major-релиза. Это имелось в виду.
Насчет «проще» — вещь индивидуальная. Нам так удобнее, я лишь предложил вариант.