LINUX.ORG.RU

Qt планирует перейти на новый цикл выпуска версий

 ,


0

3

João Abecasis из Nokia в списке рассылок Qt предложил изменить текущую систему подготовки новых релизов.

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

João предлагает перейти на фиксированный по времени цикл выпуска релизов:

  • каждые 6 месяцев — минорный релиз (5.x);
  • каждые 2 месяца — корректирующий релиз (5.x.x).

Кроме этого предлагается изменить структуру git-репозитория Qt, создав в нем следующие ветки:

  • Fire hose — основная ветка для разработки Qt. Предназначена для разработки минорных релизов, разрешает как добавление новых возможностей, так и исправление ошибок.
  • Leaky faucet — ветка для разработки корректирующих релизов, разрешает только исправление ошибок текущего минорного релиза.
  • Dripping bucket — ветка для релизов, принимаются только исправления критических ошибок.

Раз в 6 месяцев Fire hose будет вливаться в Leaky faucet для подготовки нового минорного релиза. После завершения исправления ошибок Leaky faucet будет вливаться в Dripping bucket для осуществления релиза (а также для корректирующих выпусков).

João в своем сообщении также упомянул о том, что в данном месяце должна выйти бета-версия Qt 5, а окончательный релиз должен состояться в сентябре-октябре. При этом, согласно предложенному плану разработки, Qt 5.1.0 должна появиться спустя 6 месяцев, в апреле 2013 года.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: Silent (всего исправлений: 1)

Ответ на: комментарий от Shtsh

Почитайте обсуждение. Другие зразработчики Qt (из Nokia и Intel) его поддержали.

unfo ★★★★★
() автор топика

фиксированный по времени цикл выпуска релизов

Объясните мне, в чем смысл? Зачем выпускать или недоделку, или ждать с выпуском готового?

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

или ждать с выпуском готового?

С учетом того, сколько разработчиков из Nokia попало под сокращение - это фантастика.

unfo ★★★★★
() автор топика
Ответ на: комментарий от unfo

Ну это я не только применительно к нокии. В каком вообще сферическом случае фиксированный по времени цикл имеет смысл?

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

В каком вообще сферическом случае фиксированный по времени цикл имеет смысл?

Ядро, например, релизится по времени.

unfo ★★★★★
() автор топика
Ответ на: комментарий от unfo

Ядро, например, релизится по времени.

Дооо. А как же. Ядро релизится, когда Линус считает, что очередной rc стабилен и не раньше.

Pavval ★★★★★
()
Ответ на: комментарий от vurdalak

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

Pavval ★★★★★
()
Ответ на: комментарий от vurdalak

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

Цикл в 2-3 месяца «добавление фич - заморозка - исправление багов - релиз» отработан, все к нему привыкли.

unfo ★★★★★
() автор топика
Ответ на: комментарий от Pavval

Ядро релизится, когда Линус считает, что очередной rc стабилен и не раньше.

Но тем не менее, релиз стабильно каждые 2/2,5/3 месяца. Слишком много новых патчей не принимают, чтобы было время исправить ошибки.

unfo ★★★★★
() автор топика

João в своем сообщении также упомянул о том, что в данном месяце должна выйти бета-версия Qt 5, а окончательный релиз должен состояться в сентябре-октябре.

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

dt1 ★★
()
Ответ на: комментарий от unfo

Но тем не менее, релиз стабильно каждые 2/2,5/3 месяца.

50% - это «стабильно»? Да вы России совсем забыли, что такое стабильно.

Слишком много новых патчей не принимают, чтобы было время исправить ошибки.

Merge window фиксирован по длительности, а цикл релизов - нет.

Pavval ★★★★★
()
Ответ на: комментарий от Spirit_of_Stallman

В чём новость то? Когда перейдут - тогда и постить. Идиотизм.

А чем она хуже новостей о планируемом переходе убунты на wayland?

Тем более, в данном случае каждый желающий может высказать свое мнение по этому поводу в списке рассылке Qt.

unfo ★★★★★
() автор топика
Ответ на: комментарий от unfo

А чем она хуже новостей о планируемом переходе убунты на wayland?

А где я говорил что те новости лучше?

свое мнение по этому поводу в списке рассылке Qt

Ну, в таком свете это и правда имеет смысл. Тогда я погорячился.

Spirit_of_Stallman ★★★
()
Ответ на: комментарий от Pavval

50% - это «стабильно»?

нет, 50% - это «половина»

shty ★★★★★
()
Ответ на: комментарий от Pavval

Merge window фиксирован по длительности, а цикл релизов - нет.

Merge window - 2 недели, что не так уж и много, поэтому де-факто цикл выпуска релизов все-таки является фиксированным. (Да, +/- 2 недели на выпуск релиза для такого проекта, где надежность очень критична, вполне нормально).

unfo ★★★★★
() автор топика
Ответ на: комментарий от unfo

С учетом того, сколько разработчиков из Nokia попало под сокращение - это фантастика.

А вот GTK от корпораций не зависит.

harper
()

почему бы просто не закопать? подыхает же. не мешайте.

niXman ★★★
()

и Qt туда же. Что за страсть к регулярным релизам? может, тогда и версии нумеровать как YYYY.MM ?

dotbg ★★★★
()

Эффективные менеджеры готовят Qt к продаже. А то продавать явный труп как-то неудобно.

anonymous
()
Ответ на: комментарий от vurdalak

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

думаю фиксированный цикл имеет значение и смысл

т.е. ты точно знаешь что эти наработки будут стандартизированы в течение полугода

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

I-Love-Microsoft ★★★★★
()

Fire hose — пожарный шланг

Leaky faucet — протекающий кран

Dripping bucket — капающее ведро

Что они там курят?

harper
()
Ответ на: комментарий от harper

А вот GTK от корпораций не зависит.

Вот и помянем GTK.

Pavval ★★★★★
()

Мужики, конечно, лучше знают, как им удобнее работать, но все же не понятно, зачем делать минорные (не подходящее название, имхо, в случае Qt) релизы фиксированными по времени в отличие от корректирующих, конечно. Не понятно, в чем профит: значительные изменения в случае небольшого отставания от сроков теперь либо будут пихаться сырыми, либо задерживаться сразу на полгода.

metar ★★★
()
Ответ на: комментарий от I-Love-Microsoft

выйдут будучи оттестированными не только тобой до момента добавления

Как раз наоборот. Если цикл не фиксирован, разработчики могут тестировать сколько угодно. А если есть дедлайн, то выпускают как убунту - что успели, то исправили, что не успели - жди месяц после релиза, прежде чем ставить.

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

Мне новые openjdk приходят где-то раз в пару месяцев. Так что скорее всего это твой дистр слоупочит.

vurdalak ★★★★★
()

так и вижу

Changelog:

- version number changed

upcFrost ★★★★★
()
Ответ на: комментарий от Reset

Reset

Фиксированный график релизов это всегда хорошо.

Reset

конечно, ведь так заведено в Microsoft Windows, Microsoft Office, Microsoft .NET, Microsoft Windows Server, Microsoft Shutupfuck

ой, простите, Sharepoint

pashazz ★★★★
()

каждые 2 месяца - корректирующий релиз (5.x.x).

а если косяк в безопасности, например, тоже будут два месяца ждать?

xsektorx ★★★
()
Ответ на: комментарий от vurdalak

суть в том, что если фича будет недоделана, то её попросту не пустят в релиз, а не будут ждать, пока её добьют

xsektorx ★★★
()
Ответ на: комментарий от xsektorx

Так это можно и так сделать. Если 99% фич доделана, а одна нет, никто не мешает выпустить без нее.

vurdalak ★★★★★
()

Очень даже неплохая идея.

a1batross ★★★★★
()

Они всё это придумали только ради прикольных названий веток

unC0Rr ★★★★★
()
Ответ на: комментарий от metar

+1. Фиксированный график для «минорных» релизов не нужен.

anonymous
()
Ответ на: комментарий от harper

А вот GTK от корпораций не зависит.

И он имеет просто превосходные шансы скопытиться, если по какой-то причине RedHat решит забить на Gtk+

alex-w ★★★★★
()
Ответ на: комментарий от harper


Fire hose — пожарный шланг

Leaky faucet — протекающий кран

Dripping bucket — капающее ведро

Что они там курят?



что непонятного, чем меньше течёт, тем стабильнее ветка — соленый девелоперский юмор :]

Virtuos86 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

В том-то и дело, что выживут все. Ибо пипл схавает. А делать реально эффективно никто не хочет. А зачем?

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Хорошо, ты досбавил фичу, она не очень стабильна, ну так жди не следующего 6-ти месячного релиза, а например через год. Проблема-то в чем? Лаг в 6 месяцев? А в случае нестабильного цикла релизов лаг может быть длинною в год и более.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

ну так жди не следующего 6-ти месячного релиза, а например через год

Через год выпустят релиз, где эта фича стабильна, но нестабильная другая. Ждать опять того же самого?

А в случае нестабильного цикла релизов лаг может быть длинною в год и более.

Если разработчик хочет выпустить, он выпустит раньше.

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.