Пользователь
57,4
рейтинг
3 июля 2013 в 14:07

Разработка → Github Releases: публикация релизов

Разработчики Github реализовали новую функцию Releases для удобного распространения ПО конечным пользователям. Зайдя в раздел Releases, пользователь всегда может найти последнюю версию программы, changelog и полную историю версий. Ссылка на релизы помещена на главную страницу проекта.



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



Для нумерации версий рекомендуется использовать семантическую нумерацию.



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



Если они выкатят ещё свой пакетный менеджер и платёжную систему — то получится идеальная экосистема для распространения приложений. Кто знает, в каком направлении будет развиваться Github. С недавно полученными инвестициями 100 миллионов долларов они могут сделать что только душа пожелает.
Анатолий Ализар @alizar
карма
751,5
рейтинг 57,4
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (23)

  • +18
    Полезная функционал имхо.
    • +14
      «Функциональность»:) Вы были близки:)
      • +1
        Смысл всё же чуть-чуть важнее.
  • +5
    Вроде, не так давно выпиливали скачиваемые файлы. Можно считать, что они вернулись?
    • +2
      Путаете бинарные файлы больше 100мб в репе и файлы, приаттаченые к релизу. Последние не версионируются.
      • +6
        В общем-то я догадываюсь, что Athari имеет в виду новость «Goodbye, Uploads» от 11 декабря 2012 года, в которой Гитхаб извещал владельцев проектов о том, что закрывает возможность закачивания файлов (не подвергаемых контролю версий) для последующего скачивания их пользователями.

        Теперь и впрямь получается, что возможность эта вновь возвратилася, разве что файлы эти присоединять отныне можно не ко всему проекту в целом, а только к отдельным релизам (выпускам) его.
  • +13
    скорее всего для этой фичи и выпиливали
    • +1
      Они смачно выпиливали, с предложениями «а не пойти ли вам куда подальше на source forge».
      • 0
        В справке «Distributing large binaries» первоочередное внимание уделено даже не SourceForge, а прямо Amazon S3 да CloudFront.
    • 0
      Версия интересная, но с 11 декабря прошло более полугода, так что как-то тогда слишком уж рановато, выходит, отпилили они прежнюю полезную функциональность, если новую так долго затем проектировали да внедряли.

      Мне не верится, не верится в это.
  • 0
    Вопрос по семантической нумерации: там предлагается менять мажорную версию когда ломается совместимость API. Но если мое приложение, это именно приложение, а не библиотека, то о каком API может идти речь? Ну вот пишу я очередную игру где пользователь, на этот раз, кидает свиней в птиц. И? Версии 2.0.0 не будет никогда?
    • +2
      Это замечание совершенно справедливо.

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

      Например, если Вы пишете игру, в которой пользователь кидает свиней в птиц, и для неё существует общедоступный редактор уровней (для повышения вовлечённости фанатов в процесс — а значит, для роста популярности основного движка Вашего), то тогда уместно будет выпускать:

      • очередную версию (скажем, 2.x.x) — в тот момент, когда уровни от предыдущей версии перестанут подходить к новой,
         
      • очередную подверсию (скажем, x.2.x) — в тот момент, когда уровни от новой подверсии перестанут подходить к предыдущей,
         
      • очередную подподверсию — просто по случаю улучшения, не задевающего прямую и обратную совместимость (по крайней мере, не задевающего по принципу «что-то сломалось»; улучшения по принципу «что-то не работало, хотя и должно было — но вот наконец заработало, ура!…» вполне допускаются, и даже приняты будут с превеликою благодарностию, но всё же для них подверсия лучше, чем подподверсия).

      Если же поверх Вашего приложения ничего не работает (оно самодостаточно), то ему семантическии версии и не нужны. То есть в этом случае оглашённое Гитхабом предложение использовать их Вы можете с чистым сердцем проигнорировать, Вам его никто не вменит в обязанность.
      • 0
        Думаю, в случае самодостаточности, имеет смысл мажорную версию менять, если пользователю придется серьезно переучиваться при переходе на новую версию (существенно изменился UI либо семантика приложения).
      • 0
        Ну, две версии приложения могут быть несовместимы сами с собой по, скажем, формату файлов. Тут бы семантическая нумерация не помешала.
      • 0
        Интересное предложение, но есть приложения, в которых совместимость с форматами файлов вперёд-назад между мажорными версиями поддерживается. MS Word 2013 умеет читать практически всё, что было до него. MS Word с какой-то там давней версии умеет читать все версии DOC, созданные после него, а с аддонами — и все DOCX.

        С такой философией версия MS Word не должна меняться никогда. :) (То же верно для фотошопа и других приложений, в которых не кладут болт на совместимость.)
        • +1
          MS Word, кхе-кхе, вроде чуть постарше, чем semver.
    • 0
      Приложения могут иметь опции командной строки, и иногда использоваться в скриптах, в таком случае опции командной строки и есть API
      • 0
        Я не даром свиней и птичек в качестве примера выбрал — это крайний случай, когда приложение — вещь в себе.

        Кроме того, «простые» пользователи обычно про API и не задумываются, а вот на номер версии смотрят. Смена мажорного номера версии должно нести некий message таковым пользователям тоже.
  • +1
    Вообще эти «релизы» всегда были, только назывались «тэги», но не уверен на счёт того была ли возможность создавать новый тэг в Web, и конечно же непонятно как это бинарные файлы вернулись…
    • +2
      Нельзя было создавать теги через интерфейс, к тому же появилась возможность прикреплять файлы. А так да, это просто расширение функциональности тегов.
  • +1
    Я так понял, что релиз привязывается к существущему тегу или создается, если такого нету. Но вот что происходит дальше? Я из веба создал релиз release1, прикрепил к нему заголовок, описание и бинарные файлы… Делаю у себя локально git pull – что произойдет? Запулиться последняя версия и у меня локально будет в репозитории тег release1 закрепленным за каким-то коммитом? Описание и бинарные файлы — это все только на гитхабе и никак нельзя слить себе?

    Просто вот у некоторых систем например wiki сделано так, что это не просто какие-то сущности на сервисе (не просто хранятся в БД на сервисе), а создается ветка wiki-somename, в которую сохраняются файлы с разметкой. Получается, что всегда можно синхронизироваться и ничего не потеряешь, не привязываешься к сервису.

    А так получается, что скоро понятие git и github «размажутся» и никто даже не будет понимать, что вообще-то git может существовать и без githubа.

    А вообще фича хорошая. :)
  • 0
    Очень нужная и своевременная фича: прикладывать exe-шники и deb-файлы для юзеров!

    А то приходилось код на GitHub держать, а бинарники на SourceForge выкладывать и из гитхаба ссылки делать. Еще бы сделали удобную загрузку бинарников с поддержкой докачки (ssh+wget например) и был бы вобще шоколад )
    • 0
      А я бинарник в самом репозитории держу, комичу свежий вместе с последними правками очередного релиза. И на главной странице проекта держу стабильную ссылку на его последнюю версию…

      А через релизы — меня зачем-то заставляют его каждый раз отдельно атачить. ИМХО, неудобно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.