Comments 27
Отличная вещь, давно такой сервис хотел.
Добавил пару продуктов для отслеживания. Хорошо бы вместо namespace сделать теги, т.к. не всегда можно отнести ПО к какой-то одной категории.
Например ceph — это и проект на C (как в примерах показано — что разбивается по языкам), но часто используется и без привязки к языку — как законченный продукт, тогда он Storage system или что-то вроде этого.
Например ceph — это и проект на C (как в примерах показано — что разбивается по языкам), но часто используется и без привязки к языку — как законченный продукт, тогда он Storage system или что-то вроде этого.
Да, Тимофей, мне и самому иногда бывает сложно придумать в какой namespace положить проект. Идея тегов кажется разумной. Но namespace нужен всё-равно, чтобы у каждого пакета или библиотеки был свой пермалинк.
Однако с тегами не всё так просто. Дело в том, что скоро на сервисе должна появиться возможность группировать библиотеки посредством тегов, но это, вероятно, не те теги, что ты хочешь.
Идея вот в чём — не привязывать пользователей жестко к понятию «проект», как это делает VersionEye или Gemnasium, но давать проставить библиотеке один или несколько тегов так, что потом по тегу можно увидеть сразу все изменения, которые к нему относятся. И эти теги будут видны только тебе, но не другим пользователям. В качестве тега можно будет выбрать имя проекта, hostname виртуалки или название окружения, где ты эту библиотеку используешь. Важно лишь то, что теги потом будут служить тебе напоминанием, где эту используется эта библиотека, и где её надо обновить, если вышел критический релиз.
Я пока не понимаю, как красиво и понятно дать возможность смешивать публичные и приватные теги. Разве что сделать возможным задавать более одного namespace, превратив их тем самым в публичные теги. Как ты считаешь, такой вариант годен или можно лучше придумать?
Однако с тегами не всё так просто. Дело в том, что скоро на сервисе должна появиться возможность группировать библиотеки посредством тегов, но это, вероятно, не те теги, что ты хочешь.
Идея вот в чём — не привязывать пользователей жестко к понятию «проект», как это делает VersionEye или Gemnasium, но давать проставить библиотеке один или несколько тегов так, что потом по тегу можно увидеть сразу все изменения, которые к нему относятся. И эти теги будут видны только тебе, но не другим пользователям. В качестве тега можно будет выбрать имя проекта, hostname виртуалки или название окружения, где ты эту библиотеку используешь. Важно лишь то, что теги потом будут служить тебе напоминанием, где эту используется эта библиотека, и где её надо обновить, если вышел критический релиз.
Я пока не понимаю, как красиво и понятно дать возможность смешивать публичные и приватные теги. Разве что сделать возможным задавать более одного namespace, превратив их тем самым в публичные теги. Как ты считаешь, такой вариант годен или можно лучше придумать?
Можно например публичные назвать тегами, а личные — метками.
Если сделать больше одного namespace — это и будет что-то вроде тегов, только с неправильным названием, всё же namespace (исходя из моего опыта) это жесткое деление без вариантов — как в языках программирования.
А про пермалинки — мне всё больше нравится идея с плоским именованием — как в википедии. Если что-то пересекается — добавлять в название комментарий (ну или на крайняк индекс).
Если сделать больше одного namespace — это и будет что-то вроде тегов, только с неправильным названием, всё же namespace (исходя из моего опыта) это жесткое деление без вариантов — как в языках программирования.
А про пермалинки — мне всё больше нравится идея с плоским именованием — как в википедии. Если что-то пересекается — добавлять в название комментарий (ну или на крайняк индекс).
Специфика софтварных библиотек в том, что очень часто названия будут пересекаться. Вероятность того, что и для javascript и для python c ruby и c C# найдется хотя бы одна имплементация с названием «unittest» или «requests», стремится к бесконечности. Поэтому в случае с allmychanges, логичнее всё-таки выделять некие ключевые пространства типа «язык» или «сфера применения». Пример сферы применения — «databases».
Кстати, в AllMyChanges каталог пакетов требует значительной переделки. Хочется сделать так, чтобы прямо по урлу типа allmychanges.com/p/db были видны все пакеты этого namespace.
Кстати, в AllMyChanges каталог пакетов требует значительной переделки. Хочется сделать так, чтобы прямо по урлу типа allmychanges.com/p/db были видны все пакеты этого namespace.
опять же можно сделать как в википедии — что появилось первым то и есть, если появляется что-то еще — основная страница заменяется списком того что бывает с таким названием со ссылками на предметные статьи (тут — библиотеки).
При переименованиях личные/публичные пусть следят уже за переименованной версией (как вариант можно как-то выделять старое и новое название, например старое серым шрифтом писать или наоборот обозначить что название поменялось и рядом писать новое до какого-то подтверждения). Если предполагается API — назначить каждой библиотеке id-шник и обращаться по ней.
Исходя из того что это делается для людей — то старые ссылки для людей продолжат работать, т.к. человек поймет что это список и выберет нужный вариант. А постоянные ссылки можно сделать так же по id-шникам.
Т.е. например внизу страницы написать:
и при переходе на /123 перекидывать на текущий url страницы с названием — чтобы в адресной строке было понятно где мы.
При переименованиях личные/публичные пусть следят уже за переименованной версией (как вариант можно как-то выделять старое и новое название, например старое серым шрифтом писать или наоборот обозначить что название поменялось и рядом писать новое до какого-то подтверждения). Если предполагается API — назначить каждой библиотеке id-шник и обращаться по ней.
Исходя из того что это делается для людей — то старые ссылки для людей продолжат работать, т.к. человек поймет что это список и выберет нужный вариант. А постоянные ссылки можно сделать так же по id-шникам.
Т.е. например внизу страницы написать:
<a href=" https://allmychanges.com/123">Permanent link</a>
и при переходе на /123 перекидывать на текущий url страницы с названием — чтобы в адресной строке было понятно где мы.
Вероятность не может стремиться к бесконечности ;)
Мей би ю мин «сервис релиз-нотесов»? )) Я сначала не понял — что за ноуты?
Щас все лежит — добавьте скринов что ли.
Щас все лежит — добавьте скринов что ли.
Навскидку:
1) Листаешь вниз-вниз. Что-то выбрал, а справа пусто.
Надо скроллить вверх к списку ну или слева как-то динамически отображать
2) Добрался до ресурса. Нажал follow. Всё, далее только аутентификация. Закрыть окно нельзя.
А так классную штуку запилили. Молодцы!
1) Листаешь вниз-вниз. Что-то выбрал, а справа пусто.
Надо скроллить вверх к списку ну или слева как-то динамически отображать
2) Добрался до ресурса. Нажал follow. Всё, далее только аутентификация. Закрыть окно нельзя.
А так классную штуку запилили. Молодцы!
Никита, под пунктом 1, ты, вероятно, имеешь в виду Каталог? Мне тоже не нравится, как он там сейчас организован. При большом количестве неймспейсов и пакетов, оно работает плохо. Скоро этот раздел будет переделан.
Что касается работы кнопки follow, то так и задумано. Слежение за выходом новых версий не имеет смысла без возможности присылать куда-то обновления. А для этого надо зарегистрироваться.
Что касается работы кнопки follow, то так и задумано. Слежение за выходом новых версий не имеет смысла без возможности присылать куда-то обновления. А для этого надо зарегистрироваться.
Как-то не очень понятно, зачем нужен сервис в текущем его виде, кроме общего любопытства.
Объясню на примере.
Вот добавил я Symfony, штука благополучно показала мне, что текущая версия 2.8. Но толку мне от этого мало: я не буду обновлять этот проект к себе с гитхаба пулом ветки мастер — не настолько я рисковый.
Ветка 2.8 и соответствующий чейнджлог добавлен майтейнером — это текущее состояние разработки, а не версия для установки в зависимости.
Вот что бы действительно мне помогло, так это оповещение о выходе новой версии в packagist/npm/<любимый_пакетный_репозиторий> к которому уже будет приложен действительно клёвый чейнджлог.
Объясню на примере.
Вот добавил я Symfony, штука благополучно показала мне, что текущая версия 2.8. Но толку мне от этого мало: я не буду обновлять этот проект к себе с гитхаба пулом ветки мастер — не настолько я рисковый.
Ветка 2.8 и соответствующий чейнджлог добавлен майтейнером — это текущее состояние разработки, а не версия для установки в зависимости.
Вот что бы действительно мне помогло, так это оповещение о выходе новой версии в packagist/npm/<любимый_пакетный_репозиторий> к которому уже будет приложен действительно клёвый чейнджлог.
Оповещение о том, что пакет действительно зарелизился и стал доступен в каком-то репозитории, это полезная вещь. Такие штуки довольно просто отслеживать, когда знаешь какой экосистеме принадлежит та или иная библиотека.
Правильнее всего делать не реализовывать этот механизм целиком в AllMyChanges, а положиться на один из существующих трекеров PyPi, Ruby Gems и тд., то есть договориться с другими ребятами, которые уже умеют это делать, но не умеют искать и парсить ченьджлоги. Мы работаем над этим. Скоро всё будет.
Правильнее всего делать не реализовывать этот механизм целиком в AllMyChanges, а положиться на один из существующих трекеров PyPi, Ruby Gems и тд., то есть договориться с другими ребятами, которые уже умеют это делать, но не умеют искать и парсить ченьджлоги. Мы работаем над этим. Скоро всё будет.
+ подписка на обновления конкретной ветки (2.7.* например)
А для чего нужно именно на конкретную ветку подписываться?
Например, если это LTS — ветка на которую завязан проект. В неё падают багфиксы и заплатки, о которых стоит знать чтобы не забыть обновить в проекте. А что там в новых версиях не особо интересует.
Хм, впервые мне встречается такой странный фиче-реквест. Казалось бы, разработчика должно интересовать и то, что в новых версия появляется — друг там что-то такое полезное добавят, что стоит смигрировать?
Интересует, но иначе. О новых версиях я прочитаю подробнее на досуге или по мере необходимости.
Если же смешивать информацию в один канал, то этот канал быстро потеряет свою ценность и из «относительно срочной рабочей информации» превратится в очередную рсс ленту для «потупить» на выходных.
Если же смешивать информацию в один канал, то этот канал быстро потеряет свою ценность и из «относительно срочной рабочей информации» превратится в очередную рсс ленту для «потупить» на выходных.
Кстати, для Symfony наш робот неправильно распознал из каких файлов брать release notes и нашел не то. Я там поправил в настройках, но все равно из за бага он берет данные не из всех CHANGELOG.*\.md файлов, а только из одного. Этот баг мы скоро исправим, похоже что он проявляется только когда файлы лежат в корне репозитория.
Sign up to leave a comment.
Как мы делали лучший трекер релиз-ноутов