Comments 23
Полезная функционал имхо.
Вроде, не так давно выпиливали скачиваемые файлы. Можно считать, что они вернулись?
Путаете бинарные файлы больше 100мб в репе и файлы, приаттаченые к релизу. Последние не версионируются.
В общем-то я догадываюсь, что Athari имеет в виду новость «Goodbye, Uploads» от 11 декабря 2012 года, в которой Гитхаб извещал владельцев проектов о том, что закрывает возможность закачивания файлов (не подвергаемых контролю версий) для последующего скачивания их пользователями.
Теперь и впрямь получается, что возможность эта вновь возвратилася, разве что файлы эти присоединять отныне можно не ко всему проекту в целом, а только к отдельным релизам (выпускам) его.
Теперь и впрямь получается, что возможность эта вновь возвратилася, разве что файлы эти присоединять отныне можно не ко всему проекту в целом, а только к отдельным релизам (выпускам) его.
скорее всего для этой фичи и выпиливали
Они смачно выпиливали, с предложениями «а не пойти ли вам куда подальше на source forge».
В справке «Distributing large binaries» первоочередное внимание уделено даже не SourceForge, а прямо Amazon S3 да CloudFront.
Версия интересная, но с 11 декабря прошло более полугода, так что как-то тогда слишком уж рановато, выходит, отпилили они прежнюю полезную функциональность, если новую так долго затем проектировали да внедряли.
Мне не верится, не верится в это.
Мне не верится, не верится в это.
Вопрос по семантической нумерации: там предлагается менять мажорную версию когда ломается совместимость API. Но если мое приложение, это именно приложение, а не библиотека, то о каком API может идти речь? Ну вот пишу я очередную игру где пользователь, на этот раз, кидает свиней в птиц. И? Версии 2.0.0 не будет никогда?
Это замечание совершенно справедливо.
Если у приложения Вашего есть плагины или сторонние ресурсы, которые работают поверх него, то речь идёт о совместимости его с плагинами или ресурсами, разрабатываемыми третьими лицами.
Например, если Вы пишете игру, в которой пользователь кидает свиней в птиц, и для неё существует общедоступный редактор уровней (для повышения вовлечённости фанатов в процесс — а значит, для роста популярности основного движка Вашего), то тогда уместно будет выпускать:
Если же поверх Вашего приложения ничего не работает (оно самодостаточно), то ему семантическии версии и не нужны. То есть в этом случае оглашённое Гитхабом предложение использовать их Вы можете с чистым сердцем проигнорировать, Вам его никто не вменит в обязанность.
Если у приложения Вашего есть плагины или сторонние ресурсы, которые работают поверх него, то речь идёт о совместимости его с плагинами или ресурсами, разрабатываемыми третьими лицами.
Например, если Вы пишете игру, в которой пользователь кидает свиней в птиц, и для неё существует общедоступный редактор уровней (для повышения вовлечённости фанатов в процесс — а значит, для роста популярности основного движка Вашего), то тогда уместно будет выпускать:
- очередную версию (скажем, 2.x.x) — в тот момент, когда уровни от предыдущей версии перестанут подходить к новой,
- очередную подверсию (скажем, x.2.x) — в тот момент, когда уровни от новой подверсии перестанут подходить к предыдущей,
- очередную подподверсию — просто по случаю улучшения, не задевающего прямую и обратную совместимость (по крайней мере, не задевающего по принципу
«что-то сломалось»; улучшения по принципу«что-то не работало, хотя и должно было — но вот наконец заработало, ура!…» вполне допускаются, и даже приняты будут с превеликою благодарностию, но всё же для них подверсия лучше, чем подподверсия).
Если же поверх Вашего приложения ничего не работает (оно самодостаточно), то ему семантическии версии и не нужны. То есть в этом случае оглашённое Гитхабом предложение использовать их Вы можете с чистым сердцем проигнорировать, Вам его никто не вменит в обязанность.
Думаю, в случае самодостаточности, имеет смысл мажорную версию менять, если пользователю придется серьезно переучиваться при переходе на новую версию (существенно изменился UI либо семантика приложения).
Ну, две версии приложения могут быть несовместимы сами с собой по, скажем, формату файлов. Тут бы семантическая нумерация не помешала.
Интересное предложение, но есть приложения, в которых совместимость с форматами файлов вперёд-назад между мажорными версиями поддерживается. MS Word 2013 умеет читать практически всё, что было до него. MS Word с какой-то там давней версии умеет читать все версии DOC, созданные после него, а с аддонами — и все DOCX.
С такой философией версия MS Word не должна меняться никогда. :) (То же верно для фотошопа и других приложений, в которых не кладут болт на совместимость.)
С такой философией версия MS Word не должна меняться никогда. :) (То же верно для фотошопа и других приложений, в которых не кладут болт на совместимость.)
Приложения могут иметь опции командной строки, и иногда использоваться в скриптах, в таком случае опции командной строки и есть API
Вообще эти «релизы» всегда были, только назывались «тэги», но не уверен на счёт того была ли возможность создавать новый тэг в Web, и конечно же непонятно как это бинарные файлы вернулись…
Я так понял, что релиз привязывается к существущему тегу или создается, если такого нету. Но вот что происходит дальше? Я из веба создал релиз release1, прикрепил к нему заголовок, описание и бинарные файлы… Делаю у себя локально git pull – что произойдет? Запулиться последняя версия и у меня локально будет в репозитории тег release1 закрепленным за каким-то коммитом? Описание и бинарные файлы — это все только на гитхабе и никак нельзя слить себе?
Просто вот у некоторых систем например wiki сделано так, что это не просто какие-то сущности на сервисе (не просто хранятся в БД на сервисе), а создается ветка wiki-somename, в которую сохраняются файлы с разметкой. Получается, что всегда можно синхронизироваться и ничего не потеряешь, не привязываешься к сервису.
А так получается, что скоро понятие git и github «размажутся» и никто даже не будет понимать, что вообще-то git может существовать и без githubа.
А вообще фича хорошая. :)
Просто вот у некоторых систем например wiki сделано так, что это не просто какие-то сущности на сервисе (не просто хранятся в БД на сервисе), а создается ветка wiki-somename, в которую сохраняются файлы с разметкой. Получается, что всегда можно синхронизироваться и ничего не потеряешь, не привязываешься к сервису.
А так получается, что скоро понятие git и github «размажутся» и никто даже не будет понимать, что вообще-то git может существовать и без githubа.
А вообще фича хорошая. :)
Очень нужная и своевременная фича: прикладывать exe-шники и deb-файлы для юзеров!
А то приходилось код на GitHub держать, а бинарники на SourceForge выкладывать и из гитхаба ссылки делать. Еще бы сделали удобную загрузку бинарников с поддержкой докачки (ssh+wget например) и был бы вобще шоколад )
А то приходилось код на GitHub держать, а бинарники на SourceForge выкладывать и из гитхаба ссылки делать. Еще бы сделали удобную загрузку бинарников с поддержкой докачки (ssh+wget например) и был бы вобще шоколад )
Sign up to leave a comment.
Github Releases: публикация релизов