GaretJax / phpbrowscap

Standalone replacement for php's native get_browser() function
MIT License
429 stars 69 forks source link

Fix v1 not showing on Packagist.org #41

Closed bradydoll closed 11 years ago

bradydoll commented 11 years ago

The v1 tag does not show up on the Packagist.org website (https://packagist.org/packages/garetjax/phpbrowscap).

Since the new changes (v2) are still beta, it would be great if there was an up to date v1 tag that was available to allow specifying the specific version in Composer.

quentin389 commented 11 years ago

Hi, I wouldn't want to promote version 1. I've used 2.0b tag instead of 2.0 just so people wouldn't mindlessly upgrade without checking if it works. But since I don't see any new bug reports I'm going to assume everything is fine. So, I'm probably going to make some small upgrades this weekend and bump the version to 2.0.

Is that good enough?

bradydoll commented 11 years ago

Because the only tag available through Composer up until this point was the 'dev-master', it is not possible to target the 1.0 version directly as it is not possible to specify a specific commit. This means that if you do a composer update you will get the current commit in the master branch. This makes it impossible to update other items in your composer configuration without updating to the latest version of phpbrowscap. This makes upgrading at your own pace more difficult.

I understand not wanting to promote the 1.0 version when the 2.0 version is basically ready. Perhaps when you bump the version to the full 2.0 you can add a 1.0 tag at that time. This should prevent promoting the 1.0 branch as people will see a 2.0 release (as opposed to a beta release) and be more likely to choose it.

quentin389 commented 11 years ago

OK, that makes sense.

But how do I tag release in packagist?

I just did:

git tag 1.0 916aea3c3c781
git push --tags

which is the same exact thing I did to tag version 2.0, but it didn't update on packagist

bradydoll commented 11 years ago

Actually, reading the Composer documentation, it may not be an issue after all. It is possible to update an individual package using the syntax composer update package_name. This would allow you to update a specific package without updating phpbrowscap. I was also under the impression that if you made a change to your autoload settings that you had to do a composer update. It appears that autoload information is not stored in the composer.lock file and is updated with a composer install call.

As for the tag not showing up on packagist.org, I don't know why that wouldn't work. Perhaps @Seldaek might have an idea.

Seldaek commented 11 years ago

Seems the 1.0 tag now shows up. I don't know what I missed, but I guess I am not needed here ;)

Seldaek commented 11 years ago

Well one thing is that the github hook is not set up for this package, so it can take up to 6hrs to show up after you push a tag.

quentin389 commented 11 years ago

Hi, perhaps you could set up the hook then? I don't have admin access.

The tag showed up - closing the issue.