Как изменить наклейку на упаковке для стабильной версии?

Ответ 1

Вы должны пометить свой код номером версии.

git tag -a 0.0.0

Это объявит первую стабильную версию. Если вы беспокоитесь о номере с нулевым номером, вы можете начать с чего-то вроде 0.0.1, если хотите. Постарайтесь придерживаться семантического управления версиями, если можете: http://semver.org. После этого вы должны нажать на публичный репозиторий, например git push --tags.

Обратите внимание, что вы можете использовать весь массив ярлыков стабильности в ваших тегах. Существует все, от Альфа, бета, релиз, признанный композитором. См. http://getcomposer.org/doc/04-schema.md#version для получения информации о том, как создать номер версии.

Packagist затем сканирует ваш репозиторий и обрабатывает этот тег, который является "стабильной" версией, и соответственно маркирует ваш пакет (даже с номером версии 0.0.0 - программное обеспечение 0.x не отличается от программного обеспечения 24.x в условия Composer/Packagist).

Изменить 2016-07-14

Обратите внимание, что номера версий в семантическом управлении версиями обрабатываются разными, если они начинаются с 0.x.y. Это никак не влияет на маркировку и передачу, но это влияет на то, как пользователи могут выбирать и обновлять выпущенное программное обеспечение. Любое программное обеспечение в диапазоне 0.x считается несовместимым, если вы отпустите следующее небольшое обновление 0.x+1. Оператор tilde Composer ~ не будет нарушен этим: ~0.x (с любым целым числом как x) обновится до следующей младшей версии. Оператор каретки будет вести себя иначе: ^0.x или ^0.x.y останется в диапазоне 0.x и не перейдет в любой релиз 0.x+1.y.

Лучшим способом борьбы с этим было бы начать с версий 1.x и использовать флаги стабильности для указания возможных изменений. Вы можете использовать 1.0.0-alpha1 в качестве вашей первой версии вместо 0.0.1, более поздние версии могут быть 1.0.0-alpha2 для другого "неустойчивого" (read: API не законченного/стабильного) релиза, а затем перейти на 1.0.0-beta1 для API-стабильных, но внутренне незавершенные выпуски, а затем 1.0.0-rc1 для, возможно, API-стабильных, готовых выпусков во время финальной фазы исправления ошибок, а затем 1.0.0 для окончательной версии. Больше исправлений будет 1.0.1 и выше, новые функции будут 1.1.0, несовместимые изменения API будут 2.0.0. Обратите внимание, что первые пользователи могут использовать ^[email protected] в качестве своего требования к версии и в процессе разработки всегда будут получать самое новое обновление без необходимости изменять их требования (если вы не нарушаете свой API и не активируете обновления таким образом). Это никогда не сработает, если вы перейдете по маршруту 0.x, а затем отпустите окончательный продукт как 1.0.0, потому что у вас есть хотя бы очевидное несовместимое обновление до 1.0.

Трудно решить, не знает ли будущее, полезен ли пакет и создает счастливую базу пользователей (кто выиграет от тега релиза [email protected]), или если это всего лишь интересный эксперимент, который никто не использует в производстве (aka 0.x).

Мои личные предпочтения для внутренних частных пакетов - сделать их 1.0 с самого начала. Мне приходится иметь дело с несколькими пакетами, которые начинались с 0.0.1 и немного неприятны при обновлении, потому что они зрелые, но не могут перейти на 1.0 из-за этого несовместимого шага версии, что потребует большой работы во вторичных пакетах.