Проблема номер один
И вот, в результате возникла такая идея – а что если сделать сервис, которому даешь URL, а он сам находит и показывает ChangeLog проекта? Ведь какая проблема с большинством, да что там с большинством – со всеми софтверными проектами – сложно найти, что у них изменилось от версии к версии. А в release notes, порой, можно найти интересные и полезные вещи. Разработчики Django, к примеру, пишут не только от том что изменилось, но и про всякие деприкешены и про то, как мигрировать с одной мажорной версии на другую.
В общем, невероятно ценно иметь такое место, куда можно посмотреть и оценить возможный масштаб бедствия после апгрейда всех зависимостей. Когда такого места нет, после обновления часто случается такое:
Однако даже для проекта, мейнтейнеры которого заботливо ведут ChangeLog, найти его бывает проблематично. Почему? Да потому что фреймворки и библиотеки пишут люди, а люди все разные. Кто то записывает release notes в файлике
NEWS, кто то в ChangeLog, a некоторые разбрасывают их по отдельным файликам типа docs/src/releases/1.7.rst. Хуже всех те, кто то вообще не ведет человеческих релиз ноутов и заставляет вас ползать по гит-логу и собирать крупицы знаний по коммит-мессаджам.Проблема номер два
Вторая проблема, которая логично проистекает из первой – невозможность регулярно получать обновления каждого из проектов, который тебе интересен. Ну нельзя подписаться на изменения одного файлика
CHANGES лежащего на гитхабе! Некоторые мэйнтейнеры библиотек решают эту проблему, начиная писать о релизах в блог или, что лучше, используя GitHub Releases, но и в этом случае у вас появляются разные места и способы подписки на обновления. Это всё равно, что выстраивать пирамидки из камней – рано или поздно где-то что-то развалится:
Как бы то ни было, но в рамках Django Dash 2013 мы не стали браться за решение всех перечисленных проблем, и задались целью сделать минимальный MVP, способный показывать release notes любого проекта на гитхабе. И на это у нас было 48 часов. У нас, это у меня и двух моих коллег: Гены Чибисова и Гены Кандаурова.
Первая версия AllMyChanges.com была одностраничным приложением на angular.js и бэкенда на Django. Фронтенд рисовал всё красиво (ведь именно этим фронтенды обычно и занимаются), а бэкенд выполнял всю сложную работу – клонировал репозиторий, искал там changelog, используя сложные эвристики, а если не находил, то группировал коммит-мессаджи так, чтобы сформировать release notes из них, экономя тем самым силы и время пользователей.
И всё это работало. Работало отлично.
Жаль только, что единственный судья Django Dash наш сервис не оценил. Быть может, он его даже и не попробовал. Но плох тот основатель стартапа который остановится после средненькой оценки на хакатоне. Короче, я решил сервис развивать, и наверное, сейчас это единственный из проектов, сделанных на Django Dash 2013, который до сих пор жив.
Быстро сказка сказывается да не быстро стартап делается
Особенно, когда делается он ради удовольствия и в свободное от работы время.
Примерно через 9 месяцев появилась новая версия AllMyChanges, которая решала вторую проблему и давала возможность подписаться на любые release notes и получать уведомления о выходе новых релизов.
В отличие от сервисов, которые просто отслеживать выход новых версий (VersionEye, Gemnasium, Libraries.io и т.д.), Allmychanges не только присылает нотифайку, эй, друг, смотри ангулар версии 1.2.3 вышел. В дополнение к этому мы присылаем полное описание того, что изменилось в версии 1.2.3, особенным образом выделяя места в тексте, которые относятся к исправлению ошибок, уязвимостей или ведут к обратной несовместимости.
Так же отличается и принцип работы с библиотеками. Почти все сервисы которые отслеживают выход новых версий, завязаны на конкретный язык или несколько языков, а данные берут с репозиториев типа PyPi или Ruby Gems. При этом они, как правило, работают с понятием "проект" и там нет возможности подписаться на отдельный фреймворк или библиотеку.
AllMyChanges в этом плане более гибок. Он не только доставляет вам полные release notes, но и позволяет подписываться абсолютно на всё, для чего возможно извлечь номера версий и текстовое описание. К примеру, вы можете начать вести changelog правил дорожного движения прямо на github в обычном текстовом файлике.
Затем кинуть ссылку на файлик в AllMyChanges и всё – кто угодно сможет подписаться на публикацию новых изменений ПДД! И не забудьте про семантическое версионирование.
Вы нужны нам. Да, ты, ты и ты
Этому проекту есть куда развиваться и несомненно он будет улучшаться гораздо быстрее если вы все, вот прямо сейчас, отложите чтение хабра и начнете усиленно им пользоваться. Нам нужны ваши идеи и советы для того, чтобы двигаться в правильном направлении, так что, обязательно пишите на support@allmychanges.com или в Gitter чатик.
Комментарии (27)
garex
15.06.2015 09:10Мей би ю мин «сервис релиз-нотесов»? )) Я сначала не понял — что за ноуты?
Щас все лежит — добавьте скринов что ли.
neolink
15.06.2015 10:45+3читается и правда тяжело, что-то такое «Как мы делали лучший трекер замечаний к релизам программных продуктов» или написать release-notes проще читалось бы
Svetlyak Автор
15.06.2015 10:48-1Всё верно. Я не копирайтер. И если тут есть грамотеи, я прошу оставлять свои стилистические замечания в этом тредике. Они помогут слудующим статьям быть лучше.
NikMelnikov
15.06.2015 11:10Навскидку:
1) Листаешь вниз-вниз. Что-то выбрал, а справа пусто.
Надо скроллить вверх к списку ну или слева как-то динамически отображать
2) Добрался до ресурса. Нажал follow. Всё, далее только аутентификация. Закрыть окно нельзя.
А так классную штуку запилили. Молодцы!Svetlyak Автор
15.06.2015 12:58Никита, под пунктом 1, ты, вероятно, имеешь в виду Каталог? Мне тоже не нравится, как он там сейчас организован. При большом количестве неймспейсов и пакетов, оно работает плохо. Скоро этот раздел будет переделан.
Что касается работы кнопки follow, то так и задумано. Слежение за выходом новых версий не имеет смысла без возможности присылать куда-то обновления. А для этого надо зарегистрироваться.
gaelpa
16.06.2015 01:59Как-то не очень понятно, зачем нужен сервис в текущем его виде, кроме общего любопытства.
Объясню на примере.
Вот добавил я Symfony, штука благополучно показала мне, что текущая версия 2.8. Но толку мне от этого мало: я не буду обновлять этот проект к себе с гитхаба пулом ветки мастер — не настолько я рисковый.
Ветка 2.8 и соответствующий чейнджлог добавлен майтейнером — это текущее состояние разработки, а не версия для установки в зависимости.
Вот что бы действительно мне помогло, так это оповещение о выходе новой версии в packagist/npm/<любимый_пакетный_репозиторий> к которому уже будет приложен действительно клёвый чейнджлог.Svetlyak Автор
16.06.2015 02:06+1Оповещение о том, что пакет действительно зарелизился и стал доступен в каком-то репозитории, это полезная вещь. Такие штуки довольно просто отслеживать, когда знаешь какой экосистеме принадлежит та или иная библиотека.
Правильнее всего делать не реализовывать этот механизм целиком в AllMyChanges, а положиться на один из существующих трекеров PyPi, Ruby Gems и тд., то есть договориться с другими ребятами, которые уже умеют это делать, но не умеют искать и парсить ченьджлоги. Мы работаем над этим. Скоро всё будет.gaelpa
16.06.2015 02:12+ подписка на обновления конкретной ветки (2.7.* например)
Svetlyak Автор
16.06.2015 02:13А для чего нужно именно на конкретную ветку подписываться?
gaelpa
16.06.2015 02:19Например, если это LTS — ветка на которую завязан проект. В неё падают багфиксы и заплатки, о которых стоит знать чтобы не забыть обновить в проекте. А что там в новых версиях не особо интересует.
Svetlyak Автор
16.06.2015 02:21Хм, впервые мне встречается такой странный фиче-реквест. Казалось бы, разработчика должно интересовать и то, что в новых версия появляется — друг там что-то такое полезное добавят, что стоит смигрировать?
gaelpa
16.06.2015 18:45Интересует, но иначе. О новых версиях я прочитаю подробнее на досуге или по мере необходимости.
Если же смешивать информацию в один канал, то этот канал быстро потеряет свою ценность и из «относительно срочной рабочей информации» превратится в очередную рсс ленту для «потупить» на выходных.Svetlyak Автор
16.06.2015 20:07Разумно. Но где ты почитаешь о том что вышло в новых версиях? Я имею в виду, есть ли у тебя идеи, как разделить срочную и несрочную информацию в рамках AllMyChanges?
Svetlyak Автор
16.06.2015 02:19Кстати, для Symfony наш робот неправильно распознал из каких файлов брать release notes и нашел не то. Я там поправил в настройках, но все равно из за бага он берет данные не из всех CHANGELOG.*\.md файлов, а только из одного. Этот баг мы скоро исправим, похоже что он проявляется только когда файлы лежат в корне репозитория.
rekby
Отличная вещь, давно такой сервис хотел.
rekby
Добавил пару продуктов для отслеживания. Хорошо бы вместо namespace сделать теги, т.к. не всегда можно отнести ПО к какой-то одной категории.
Например ceph — это и проект на C (как в примерах показано — что разбивается по языкам), но часто используется и без привязки к языку — как законченный продукт, тогда он Storage system или что-то вроде этого.
Svetlyak Автор
Да, Тимофей, мне и самому иногда бывает сложно придумать в какой namespace положить проект. Идея тегов кажется разумной. Но namespace нужен всё-равно, чтобы у каждого пакета или библиотеки был свой пермалинк.
Однако с тегами не всё так просто. Дело в том, что скоро на сервисе должна появиться возможность группировать библиотеки посредством тегов, но это, вероятно, не те теги, что ты хочешь.
Идея вот в чём — не привязывать пользователей жестко к понятию «проект», как это делает VersionEye или Gemnasium, но давать проставить библиотеке один или несколько тегов так, что потом по тегу можно увидеть сразу все изменения, которые к нему относятся. И эти теги будут видны только тебе, но не другим пользователям. В качестве тега можно будет выбрать имя проекта, hostname виртуалки или название окружения, где ты эту библиотеку используешь. Важно лишь то, что теги потом будут служить тебе напоминанием, где эту используется эта библиотека, и где её надо обновить, если вышел критический релиз.
Я пока не понимаю, как красиво и понятно дать возможность смешивать публичные и приватные теги. Разве что сделать возможным задавать более одного namespace, превратив их тем самым в публичные теги. Как ты считаешь, такой вариант годен или можно лучше придумать?
rekby
Можно например публичные назвать тегами, а личные — метками.
Если сделать больше одного namespace — это и будет что-то вроде тегов, только с неправильным названием, всё же namespace (исходя из моего опыта) это жесткое деление без вариантов — как в языках программирования.
А про пермалинки — мне всё больше нравится идея с плоским именованием — как в википедии. Если что-то пересекается — добавлять в название комментарий (ну или на крайняк индекс).
Svetlyak Автор
Специфика софтварных библиотек в том, что очень часто названия будут пересекаться. Вероятность того, что и для javascript и для python c ruby и c C# найдется хотя бы одна имплементация с названием «unittest» или «requests», стремится к бесконечности. Поэтому в случае с allmychanges, логичнее всё-таки выделять некие ключевые пространства типа «язык» или «сфера применения». Пример сферы применения — «databases».
Кстати, в AllMyChanges каталог пакетов требует значительной переделки. Хочется сделать так, чтобы прямо по урлу типа allmychanges.com/p/db были видны все пакеты этого namespace.
rekby
опять же можно сделать как в википедии — что появилось первым то и есть, если появляется что-то еще — основная страница заменяется списком того что бывает с таким названием со ссылками на предметные статьи (тут — библиотеки).
При переименованиях личные/публичные пусть следят уже за переименованной версией (как вариант можно как-то выделять старое и новое название, например старое серым шрифтом писать или наоборот обозначить что название поменялось и рядом писать новое до какого-то подтверждения). Если предполагается API — назначить каждой библиотеке id-шник и обращаться по ней.
Исходя из того что это делается для людей — то старые ссылки для людей продолжат работать, т.к. человек поймет что это список и выберет нужный вариант. А постоянные ссылки можно сделать так же по id-шникам.
Т.е. например внизу страницы написать:
и при переходе на /123 перекидывать на текущий url страницы с названием — чтобы в адресной строке было понятно где мы.
Lynn
Вероятность не может стремиться к бесконечности ;)
Svetlyak Автор
Может. Это когда очень, Очень вероятно! :)