How does Composer know the Patch Version of my Package?

I think there's a version control file, I don't update that often.

But where? And what goes in it?

I know that there's a composer.lock file, but that serves a different purpose.

Each "version" is just only a branch of each repo

Well, lets suppose your package is holding the 1.2.14 version.

Major: 1 Minor: 2 Patch: 14

ok?

Now, the composer.

If you ask for "vendor-you/package-yours": ^1.2.0 Will be valid for all patchs inside 1.2 minor version (until the 1.3), and everytime you run Update, your composer.lock file will save the last patch version you are using...

@wolle404 Then why doesn't Laravel have 5.1.1, 5.1.2, 5.1.3, ... , and 5.1.40 branches? It only has a 5.1 branch.

@ricardovigatti Yes, I know this, and that's not what I asked.

I'm wanting to create a package. I know how to use packages, and I know how versions are specified on the composer.json file for pulling in other packages.

If I want to have patch versions on my custom built composer package, how do I specify these without a branch for each patch (Minor versions will have their own branches)?

@tylernathanreed, When creating packages, the logic is the same, you specify the required packages just like you specify for you root application... Sorry for my misunderstanding.

Another thing is: The Laravel repository at github has a lot of patch branches. But you are looking only at the release branches. If you switch the tab on Branches to Tags you're gonna see.

@ricardovigatti Tags might just be the solution I was looking for. I thought that this was done with Tags, but I couldn't find it on the Laravel Framework Repository.

Turns out that was because GitHub doesn't show that option on mobile, and that was where I started doing my research.

Let me assert an answer, and tell me if I'm understanding this correct:

To inform Composer of a Patch Version, I apply a Tag to specific Commit that should represent that Patch. The name of the Tag should match the Composer Versioning pattern, meaning a Tag of v5.1.22 maps to laravel/framework: "5.1.22". And using laravel/framework: 5.1.* grabs the latest Patch based on the version.

That said, what's the difference between a Release and a Tag in terms of GitHub?

See: https://packagist.org/about

New versions of your package are automatically fetched from tags you create in your VCS repository.

The easiest way to manage versioning is to just omit the version field from the composer.json file. The version numbers will then be parsed from the tag and branch names.

That said, what's the difference between a Release and a Tag in terms of GitHub?

Nothing.

@tylernathanreed This is a thing about the integration between packagist and github (or git, i don't know..).

Complementing what @willvincent said above, you have the option to manually control your package version, inserting the "version" property on composer.json file. But this is a good approach only in a few cases.

@ricardovigatti Even Composer itself recommends against specifying a Version Number, as humans are prone to errors.

@willvincent How unusual. That's quite an odd feature to duplicate.

@tylernathanreed It's not really a duplication.. Releases are metadata that go along with a particular tag, and not all tags are a 'release' automatically. A tag is really just flagging a certain point in a codebase's timeline, a release associates a title, description (change log usually), etc with a particular tag. As far as I'm aware, the release metadata doesn't exist anywhere but on github, in otherwords, it's not part of the git repo directly.. I could be wrong there though.

So I guess there is technically a different, but a release depends on a tag. Tags are just flags or labels that point to a particular commit in a project's timeline, they are not necessarily a release.

@willvincent Then can I have a Tag that doesn't refer to a Release?

@tylernathanreed Certainly. Create all the tags you want. Only create releases for tags that are, in fact, releases.

Tags are really just a method of bookmarking a particular snapshot of a code's history. A release, in turn is associated to one of those bookmarks (tags).

@willvincent All of the Tags that I've created for my repository are automatically made as Releases on GitHub. Is this because my tags are using the vX.Y.Z notation?

I don't know.. read Github's releases documentation. :)

Github releases are "lightweight tags" so if you're creating tags that way, then yes that might automatically generate a relase.. I have no idea.