Версии ночных сборок

[Tolik]

Ну так для чего roadmap придуман?
Первоочередным багам и хотелкам надо поставить target 1203xx, остальным - более отдалённый.
И кажется, vdemidov уже начал наводить порядок.

По версиям программы открыл хотелку 1138.

[Parasite]

Не пора ли прислушаться к Толику и сделать релиз, с прошлого года-то?

Пора бы. Но тогда уже прямо сейчас надо объявить мораторий на совсем новые хотелки (разве что "деревянные" настройки хотелось бы увидеть и заюзать), и до релиза допиливать только уже начатые, ну и конечно устранять кривоту всякую. Тогда к марту выйдет стабильный релиз.

+1
А хотелки никогда не кончатся - с мораториями или без, так что релизить все равно придется независимо от их числа.

И имхо ссылку на ночнушку надо хотя бы с главной убрать (чтобы не плодить кучу версий у хомяков, и потом самим же не путаться в них при разборе полетов в багтрекере - коль скоро там нет на каждую ночнушку по отдельной ветке). По идее бы на главной оставить только кнопку на релиз, а далее где-нибудь на страничке сделать не такую заметную ссыль на страницу "Предыдущие и тестовые версии", на коей уже и хранить все кучи файлА. То есть - так, как сделано у других проектов.
95% хомяков на эту страницу не пойдут ввиду очевидных причин (при наличии большой красивой кнопки на релиз на главной), а те кому нужна будет именно старая или тестовая версии - найдут эту страницу и самостоятельно, и про них и их уровень\число и качество багрепортов уже совсем другой разговор.

А сейчас, в виде двух равноправных ссылок совершенно рядом на весьма разные даже по функционалу версии (практически две разные программы, я бы сказал) - это бардак, извиняюсь. 99% хомяков ночнушки не нужны и даже вредны - однако с 50% вероятностью на нее хомяк кликнет (и поимеет. и запустит. и в ОЧЕРЕДНОЙ раз отпишет гневный рапорт о том ХХХ у него не запустилось\не заработало\попросило отправить платный СМС\еще что-то, он убил кучу времени\файла\ресурсов\нефти, а ему в очередной раз будут обьяснять что ИМЕННО В ЭТОЙ версии так и должно быть и глюки ХХХ даже приветствуются, и что всех предупреждали и все такое, итд итп - как это вон в соседней ветке про беркли).

Резюмэ: не допускать настолько большого отрыва ночнушек от стабильного релиза. Хомяк, хотящий уже стабильную введенную полгода назад фичу ХХХ но получающий полный набор глюков от тестовых фич YYY в той же ночной версии что и XXX (бо в последнем релизе этого еще не было) - это злой и недобрый хомяк. Предлагаю не копить все яйца в одной корзинке по году - и оттестированные фичи таки выливать почаще в релизы и на главную. Имхо.

[vdemidov]

Не вопрос. Делайте релиз. Делайте ветки Alfa, Beta, Release. Кто ж мешает? Я потихоньку буду ковырять то, что считаю нужным. И коммитить буду в default ветку. А уж в какую ветку эти изменения потом вливать Alfa, Beta, Release можете решать сами. Если кто-то займется, то я буду только рад.

[Parasite]

Я потихоньку буду ковырять то, что считаю нужным

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

PS: а настолько ли сложно сделать автообновление в программу? Просто вопрос (сделать самому - не предлагать, я на дельфе не ездун и сто раз об этом публично сообщал).
Теоретически можно было бы сделать на хостинге скрипт, автоматом сливающий ночнушку месячной давности в релиз (месячной - чтобы иметь время пофиксить все критические глюки в текуем .current, если что-то где-то внезапно случайно отломается, как например сведение в жпег вчера). А дальше - предложение автообновления уже у хомяков в штатном порядке, кто (не) обновился - сами себе виноваты.

[vdemidov]

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

[vasketsov]

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

Это потребует как раз разделения current\release\stable, чего всеми силами хочет избежать не только vdemidov.

Я потихоньку буду ковырять то, что считаю нужным

Дело не в ограничениях на внесение изменений.
Дело в повышении приоритета для недоделанных и неоттестированных доработок, которые не позволяют считать версию достаточно стабильной для публикации.
Если разработчиков больше 1 - в момент релиза необходимо иметь общее представление о стабильности продукта в целом - в этом смысле без согласования действий по-любому никуда не деться.

Если исходить из желания выпустить стабильный продукт и не выделять отдельно релиз, то понятно, что момент выпуска должен основываться на представлениях разработчиков (коли нет отдельный тестеров с полномочиями выпуска продукта) о стабильности конкретного билда. Мнений этих может быть много разных. Но выдёргивать недоделанное по мнению самого разработчика никто не будет, а если их много - вероятность того, что все в конкретный момент случайно закончили свои дела до некого стабильного состояния - стремительно стремится к нулю. Вот и получится что имеем - бесконечное откладывание релиза.
Чтобы повысить стабильность релиза после очередного "йа кончелъ" от одного из разработчиков - очевидно в этот момент другие на должны быть в процессе революции в коде. Не вижу другого способа, чтобы что-то нужное делать и без революций после некой отмашки типа "релизная готовность", чем "вялотекущая шизофрения" в виде доделывания всяких TODO, раскомментирования закомментированного, ну и прочие неинтересные и непопулярные дела, которые можно бросить почти в любой момент и которые в принципе не так уж необходимы, если в целом всё работает (если другой начал революцию - ничего не останется, как ждать его "кончины", или не мёрджить и не включать модификации в релиз). Это сильно уменьшит вероятность перевыпуска релиза через несколько часов\дней после выпуска (правда если честно, в перевыпуске тоже ничего страшного нет, если кривой релиз не по%ерит данные - прежде всего конечно кэш карт и метки).

зы. Месячная оценка исключительно моя, на основе опыта именно по current\release\stable для такого количества доработок и для отдельных тестеров, тут может быть всё сильно иначе, ибо ночнушки фактически и так тестируются.
ззы. Самое забавное как раз то, что разработчикам релизы-то и не нужны особо, я с сентября пользуюсь только ночнушкой, за исключением пары случаев когда не помню уже что отваливалось.
зззы. Помнится я как-то уже писал тут на форуме, что нельзя, чтобы в процессе разработки, выпуска и поддержки продукта главным(и) был(и) разработчик(и). Тему искать лениво.

[vdemidov]

Это потребует как раз разделения current\release\stable, чего всеми силами хочет избежать не только vdemidov.

Я не хочу этого избежать. Я не хочу тратить на это свои силы и время.

ззы. Самое забавное как раз то, что разработчикам релизы-то и не нужны особо, я с сентября пользуюсь только ночнушкой, за исключением пары случаев когда не помню уже что отваливалось.
зззы. Помнится я как-то уже писал тут на форуме, что нельзя, чтобы в процессе разработки, выпуска и поддержки продукта главным(и) был(и) разработчик(и). Тему искать лениво.

А кто может быть главным в данном случае, если для все разработчиков программа исключительно хобби?

[Tolik]

если другой начал революцию - ничего не останется, как ждать его "кончины", или не мёрджить и не включать модификации в релиз

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

Можно сделать и проще -некая одноразовая акция.
Вот прямо щас давайте составим список, что именно мешает обозвать ночнушку релизом.

1. баг 1137 - сломалась склейка (и копирование, кстати, тоже) - критично
2. 1088 - плохо выделяется по треку - не особо критично (в релизе вообще не выделяется)
3. 1131, 1132, 1133 - глючит менеджер меток - не критично (кажется, в релизе глючит точно так же)
4. 1090 - неправильно отображается время из-за изменений в часовых поясах - не критично (в релизе, очевидно, так же)

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

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

P.S. Эту одноразовую акцию можно считать мораторием на внесение любых изменений, кроме как исправление нескольких критических багов
P.P.S. Собственно список составлять и не надо, надо только исправить target у некоторых тикетов в багтрекере, и исправлять только те, которые окажутся в roadmap-е наверху. http://sasgis.org/mantis/roadmap_page.php

[vdemidov]

Я считаю, что БерклиДБ нужно в релизе вообще отключить и не добавлять никаких упоминаний о ней. Потому что процесс переключения типа кэша работает через задницу.

[Tolik]

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

Это технически просто?
Может быть, убрать только пару строк из гуёв?