Composer/Packagist not giving me my latest package

Question

If you go you https://packagist.org/packages/geekality/website and compare it with what you get when you run `composer show geekality/website.

1. Latest version at packagist at the top is v0.7
2. Latest version given in command line output is v0.6
3. Latest version should have been v0.7.1 in both cases
4. Version >= 0.7 doesn't even show up in the command line
5. The dev-master version points to v0.5 ??

What is going on here? How do I fix this? If I change my composer.json to target version/tag 0.7.1, which to me clearly exists on both packagist and on GitHub, I get an error message saying the requested package could not be found.

I have tried

• Delete vendor folder and re-update
• Delete the composer cache
• Do the composer update on a different computer
• Delete and recreate the package on Packagist
• Create and push a new tag (0.7.1 is basically same as 0.7)

Anyone have any idea what's going on?

---

Update

Seems like this is caused by some issues with Packagist and that nothing is actually wrong on my side (or others who seem to have the same problem).

I "solved" it temporarily by listing the source of problematic repositories manually in composer.json.

Answer 1

The solution in this case was to wait for Packagist to not be broken.

So, if anyone else have this issue and they have checked all their stuff, maybe check twitter or something to see if anyone else are having issues.

Answer 2

It looks like you stuffed up either your tags or moved origin/master back to an earlier version.

It is version v0.5 that still has the origin/master and master tags associated with it which is very odd.

I think you want to just reset master to the lastest commit, however you probably ought to figure out how this happened first, in case there's something even weirder going on.

The way I tag versions is:

1. Check in and push everything to the remote repository.
2. Run git tag 1.2.3 on a command line.
3. Push the tags on the command line git push --tags

I think you may have caused this issue by skipping step 1 and still having uncommitted changes locally. If you can push those commits, that might fix the problem, otherwise you may need to reset the head to the appropriate version.

In Atlassian Sourcetree that can be done by right clicking on the appropriate checkin, otherwise you can do it from the command line with the git reset command:

git reset --soft a4ed43d16ecb20aaa275ee120e073e043190e093

Does not touch the index file nor the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.

That should not delete anything either locally or remotely, but just change where the head is pointing to.