Add "abandoned" to composer.json schema.

[SvenRtbg]

I do like the fact that data structures seem to be the same in both composer.json and Packagist.

The feature to mark packages abandoned currently is a meta feature implemented in the Packagist UI. As soon as a package is marked, all published versions and branched inherit this flag.

To allow doing the same for my local Satis instance and private repos, I discovered that Satis will happily consume the "abandoned" flag from the composer.json file and integrate it into it's own package metadata. I know it's limited to the branch this has been committed and that you usually cannot change tags, but I like the idea that the source repository is able to communicate the package status directly instead of indirectly. My own afterburner script reads the created Satis metadata and propagates the "abandoned" flag to all tags.

Now the issue is: The schema for composer.json does not allow adding "abandoned":true or "abandoned":"other/package", and I think it should be added.

It would open a way for source repos to communicate the status of a package without the need for another channel. However, it's unclear on the consuming side how to deal with this info beyond "pass it through unaltered", and I'd think this would be out of scope for this issue.

[Seldaek]

Makes sense I think, it's just a validation change anyway, it's nothing you can't do yet. The only thing is packagist will ignore the abandoned flag and it'll still require you to do that in the UI but I think that's for the best.

[aidantwoods]

I'm interested in the scope of the abandoned key (I can't find any docs for it) :)

Would committing "abandoned": true as a final patch release to EOL versions of a package have any adverse effects on later versions of the same package (i.e. same repo) that did not have this key in their composer.json?

The intent here being to try and push users off say 1.x if the package owner does not intend to maintain this version, but is actively maintaining 2.x, say.

cc: @thiagooak since he authored the commit.

[Seldaek]

The notion of "abandoning" a package on packagist is package-wide, so no please don't do this on a per-version basis as the wording will be all wrong and you might confuse users. IMO people should check composer outdated to see what they can update and if something has a new major release it's kinda obvious you should go there whenever possible.

[aidantwoods]

The notion of "abandoning" a package on packagist is package-wide, so no please don't do this on a per-version basis as the wording will be all wrong and you might confuse users.

Yeah, this was really the motivation for asking – wouldn't want to accidently have this effect.

IMO people should check composer outdated to see what they can update and if something has a new major release it's kinda obvious you should go there whenever possible.

IMO it would be nice to have composer support abandonment via a version constraint too (and perhaps have adjusted wording) :) The abandon feature exists so package authors can be responsible and give users a heads up when development ceases, I think we should be able to do the same thing for versions that have the same fate.

I don't think that composer outdated does this job because:

1. It requires users to proactively check (abandon gives them notice)
2. Existence of new major versions doesn't mean the one you're using isn't supported. While it might be a good idea to update if a new major version exists, it additionally becomes dangerous not to if the one you're using is no longer supported

Hope that makes sense :) I'll put this in a new issue (#7223) since this has turned into more of a feature request now.