作曲家包的Git工作流程？

I've been developing a lot of packages for composer recently, as our company is moving to composer for package management, but I'm running into issues with how to handle versions.

I've been using the git workflow, with tagged releases, but this means I can't go back to a previous major or minor release and make a patch release for it. I also have been running into issues with understanding how tagged development/beta/RC releases work with composer.

I've seen other projects use branch aliases, and I think it might solve these issues for me, but after reading the composer docs on them I still don't feel like I understand how to practically use them.

Does anyone with more experience using composer have tips/tricks on how best to version a git package repository?

1. Source Control of Composer project

I normally ignore the vendor directory using .gitignore. Indeed, this is so common that .gitignore file comes with most PHP framework would have already included the vendor directory.

Upon release, some of the steps will be:

  • checkout or clone from release branch/tag,
  • update composer ( self update )
  • composer install ( install all dependencies into the vendor directory )

2. Composer versoining/stability/alias confusion

Yes this is confusing, I think the most confusing part is where versions come from, and it is not easy found in the online docs. Versions come from source control's branches and tags

  • a Tag name is the exact version name. if you have a tag called 'xx', you can reference it in the package.json file as 'xx'. if your tag follows the semantic naming convention (e.g. 1.0.1 or v1.0.1), you can refer to it using semantic syntax like ~1.0.*.
  • tags are 'stable' UNLESS their semantic names contains somethings like 'RC1', 'RC2', 'alpha' etc. (e.g. 1.0.1-rc1, 1.0.1-alpha) In those cases they can be referenced by 1.0.1@RC or 1.0.1@alpha.
  • branches are not 'stable' by default, numbered branch will be treated as development version. e.g. branch 2.0 will be referenced as 2.0.x-dev (note the extra .x ); Non-numbered branch name will be referenced with be prefixed with 'dev-'. i.e. 'master' branch becomes dev-master and 'testing' branch becomes dev-testing.
  • Branch alias is used, for example, when you want to treat the master branch as 2.0.x@dev. You might want to use the dev-master branch of package ABC but it happens that one of the packages you used in your project depends on the 2.0 branch of package ABC. As you can only use one version of package ABC in your project, you basically ask all other packages to use the dev-master when they want to use the 2.0.x@dev branch

Other issues like minimum-stability and nested dependencies are clear in the online docs and I am not repeating them here.