Packagist

[dereuromark]

Packagist

[BenBE]

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.

[mermshaus]

I’ve been trying to figure this out for quite some time, but I didn’t find a good solution.

Tags are historically named RELEASE_major_minor_parser_release which somehow conflicts with packagist naming conventions. Can this be overwritten?

Unfortunately, I don’t think so.

Apart from this: Commits on master are always kept working - if not to say: I'm running master on the qbnz.com website demo.

The problem with having only dev-master and no tagged (in a way Packagist understands) releases is that a require line "geshi/geshi": "dev-master" in one of your own packages/libraries (let’s call it foo/bar) makes that package “unstable”, and there doesn’t seem to be a way to overwrite that within the package itself.

When somebody wants to use your foo/bar lib (that requires geshi/geshi), they can’t simply run…

$ composer require foo/bar

…or add a line…

{
    "require": {
        "foo/bar": "~1.0"
    }
}

…to their composer.json file because this only works with stable packages.

What they’d have to do is either changing the minimum-stability requirement to dev (which is a bad idea, imo) or explicitly adding "geshi/geshi": "dev-master" (or something like that) to the root project’s composer.json file:

{
    "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.

1. Add a second set of Git tags to the repository that follow a format Packagist understands. As a format, e. g. v1.0.8.12 or 1.0.8-p12 would work. These tags and the RELEASE_* tags can exist alongside each other. If you can live with the redundancy, this is probably the best solution. It is kinda unsatisfactory having to add a special set of tags just for a single package manager, but I guess the format is generic enough.
2. Create a “fork”/second repository that mirrors GeSHi’s code and adds tags Packagist understands. Think geshi/geshi-packagist. That’s what some people have done in the past. It works, it leaves the original repo alone, but it feels unnecessarily complicated to have different repos, perhaps even with different sets of maintainers. I’d want to avoid that.
3. Put the “burden” on every developer who wants to use a package that requires GeSHi. That’s the solution I outlined above and more or less the status quo. If you want to add a lib that uses GeSHi via Composer to your project, you have to add a line for geshi, too. This doesn’t look like much of a problem, but I would argue that this situation really holds the geshi/geshi package back in regards to usage via Composer/Packagist. (Besides the fact that only having dev-master pretty much means “there is no stable version” from a Composer user’s point of view.)

[mosbth]

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:

    "require": {
        "php": ">=5.4",
        "michelf/php-markdown": "1.5.*",
        "ezyang/htmlpurifier": "4.*",
        "geshi/geshi": "1.0.*",
        "ext-json": "*"
    },

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 👍

[peterdd]

Tags are historically named RELEASE_major_minor_parser_release which somehow conflicts with packagist naming conventions. Can this be overwritten?

Unfortunately, I don’t think so.

Why not?
What would be wrong to release the next version as v1.x.y (replacd x and y with numbers)? v comes after R in the alphabet and shouldn't composer or packagist handle this right? v1.x.y is also a suggested version numbering by github.com

[mermshaus]

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 RELEASE_1_0_8_12 format, but Packagist doesn’t understand it. (The service only works with very specific tagging formats. There are probably reasons for that.)

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.)

[cweiske]

@BenBE: I've tagged the current version as "v1.0.8.12", which is understood by composer. Future versions will have this tag format.

[BenBE]

@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).

[cweiske]

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.

[cweiske]

And 1.0.9.0 will NOT break PHP5 but break PHP4. PHP5 is totally fine.

[BenBE]

Correct, but if PHP5 breaks, you'll be likely on your own.