Comments (10)
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.
from geshi-1.0.
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.
- 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
or1.0.8-p12
would work. These tags and theRELEASE_*
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. - 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. - 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 thegeshi/geshi
package back in regards to usage via Composer/Packagist. (Besides the fact that only havingdev-master
pretty much means “there is no stable version” from a Composer user’s point of view.)
from geshi-1.0.
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 👍
from geshi-1.0.
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
from geshi-1.0.
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.)
from geshi-1.0.
@BenBE: I've tagged the current version as "v1.0.8.12", which is understood by composer. Future versions will have this tag format.
from geshi-1.0.
@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).
from geshi-1.0.
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.
from geshi-1.0.
And 1.0.9.0 will NOT break PHP5 but break PHP4. PHP5 is totally fine.
from geshi-1.0.
Correct, but if PHP5 breaks, you'll be likely on your own.
from geshi-1.0.
Related Issues (20)
- New release tag HOT 8
- Use of a Broken or Risky Cryptographic Algorithm in geshi/geshi.php HOT 6
- Support Json format HOT 10
- scilab highlighting has not valid html links HOT 1
- scilab highlighting refers old docs HOT 3
- <CODE SAS> highlighting inside PROC SQL HOT 5
- Deprecated: Function create_function() is deprecated HOT 1
- Use keyword parser control for roff
- 'Perl 6' has been renamed as 'Raku'
- Website out of date
- Please repair qbnz.com
- Typo in Swift keyword
- Add synonyms for conventional well-known languages/extensions
- TSQL syntax highlighing error HOT 1
- Case sensitivity & array index
- Php8.1 brokes
- Go highlighting borks on numbers HOT 3
- qbnz.com down
- Thank You
- Security contact HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geshi-1.0.