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

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



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



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



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



    Если они выкатят ещё свой пакетный менеджер и платёжную систему — то получится идеальная экосистема для распространения приложений. Кто знает, в каком направлении будет развиваться Github. С недавно полученными инвестициями 100 миллионов долларов они могут сделать что только душа пожелает.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 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
                            А я бинарник в самом репозитории держу, комичу свежий вместе с последними правками очередного релиза. И на главной странице проекта держу стабильную ссылку на его последнюю версию…

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

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