-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packagist #62
Comments
Tags are historically named RELEASE_major_minor_parser_release which somehow conflicts with packagist naming conventions. Can this be overwritten? Apart from this: Commits on master are always kept working - if not to say: I'm running master on the qbnz.com website demo. But I can update the composer.json t point to the correct vendor/project name. |
I’ve been trying to figure this out for quite some time, but I didn’t find a good solution.
Unfortunately, I don’t think so.
The problem with having only When somebody wants to use your $ composer require foo/bar …or add a line… {
"require": {
"foo/bar": "~1.0"
}
} …to their What they’d have to do is either changing the {
"require": {
"foo/bar": "~1.0",
"geshi/geshi": "dev-master"
}
} This seems to work and, honestly, isn’t too much hassle, but it isn’t the most elegant thing to do, either. Is there a way to solve this? I have done a fair bit of research (text is in German) and I’ve come up with three ideas (one of them basically being the one mentioned above) that all have advantages and disadvantages.
|
I was really glad to find that this package was on composer now. I was also trying to find how to get the latest stable release from composer and ended up here. It is a bit scary to depend on a library through "dev-master", even if that should be fine from what you say here. That is what I will do for now, no problem. But an improvement would be to add some tag that Packagist understands. Perhaps 1) as @mermshaus outlines above. That would allow me to include Geshi as something like this:
When one includes many libraries one wants to sleep well at night and one way to do so is to rely version numbers. By the way - thanks for moving to Git and Packagist 👍 |
Why not? |
The point in the part you quote is that there doesn’t seem to be an option in Packagist/composer.json to map a custom tagging format to a format Packagist understands. Actually, all needed information (major, minor, revision, patch versions) is there with GeSHi’s Changing the tagging format or adding a second set of tags (with a format compatible with Packagist) could be a solution for this issue (see my previous post). Though doing so might be considered as some kind of backwards compatibility break or might confuse existing tools/users. I don’t think that’s very likely, but it’s not a bad idea per se to at least think about being conservative with such things. (I don’t really support the idea, but one could argue whether this is rather a problem with Packagist. GeSHi is way older than Packagist, and, in general, provides the needed info. The tagging format wanted by Packagist seems reasonable enough, but one might argue that the Composer/Packagist guys are pushing “their” idea on how to do such things a bit too much in certain areas. Their stance on this is pretty much: “Projects have to adapt.” Then again on the other hand, standards aren’t bad.) |
@BenBE: I've tagged the current version as "v1.0.8.12", which is understood by composer. Future versions will have this tag format. |
@cweiske Can you also add the old versions in this format? TIA. As we already are at the versioning format: I aim to keep everything within the third digit of the version compatible as much as possible. Thus all 1.0.X.Y will work with the baseline API, independent of the Y used, as long as X stays. Noting this, because there will be 1.0.9.Y soon, which will break for everybody using PHP 5 or below (and yes, 1.0.8.13 still will be compatible to some anchient PHP version). Thus: If you require PHP 4/5 compat: 1.0.8.13 will be your last call; GeSHi 1.0.9.X will be PHP7+ only (may run on PHP5, but unsupported). |
I've added the old versions in the new tag name format. This is consistent, but does not help with packagist since the old versions never had a composer.json file. |
And 1.0.9.0 will NOT break PHP5 but break PHP4. PHP5 is totally fine. |
Correct, but if PHP5 breaks, you'll be likely on your own. |
Can you please publish via packagist to make composer pull in via tags instead of dev-master?
Refs https://github.com/markstory/cakephp_geshi/blob/master/composer.json#L32
The text was updated successfully, but these errors were encountered: