Remove version 2014-12-11 from Packagist?

[remcotolsma]

Is it possible to remove version/tag 2014-12-11 from Packagist? It looks like Composer thinks that 2014-12-11 is the latest version. Would be nice if 0.9.0 is used, and maybe later this week 0.10.0 (#631 (comment)).

[GaryJones]

We've had that commit also tagged as 0.3.0 for a long while now.

@WordPress-Coding-Standards/admins - what are your opinions on removing the date-based tag(s), with the thought that sufficient time has passed that folks should be using much newer releases anyway?

[jrfnl]

@GaryJones Is it possible to rename a tag, but still let it keep the release date it has ? (So as not to screw up the release order)

Apart from the 2014-12-11 release, there are two other date based releases which don't have an alternative tag yet.
I've used the tags for the @since versions of classes in #651 and while I don't mind changing these in the PR, removing the @since tags altogether - or leaving a @since tag referencing a release which can no longer be found feels wrong.

Or maybe just adding a release title through release notes might change things for Packagist ? Not sure how those work together. Want me to test it ?

[Rarst]

I think it should be just deleted on Packagist? (I can do this)

I don't see any other date releases there.

[jrfnl]

@Rarst If that's possible without it coming back on the next sync, that would most definitely be the simplest solution 🏆

[Rarst]

Removed on Packagist (and should stay removed afaik).

[Rarst]

Nope, it came back... Probably have to delete the tag too. :\ Ok on that?

[jrfnl]

FYI I've updated the docs PR for the tag name change.

[Rarst]

Deleted the tag, think Packagist caught up with that too.

[corysimmons]

I just composer required this yesterday and got 2014-12-11.

The README instructions (https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards#composer) don't make a lot of sense to someone trying to add this to an existing composer.json.

• create-project can probably be require
• wp-coding-standards/wpcs:dev-master doesn't seem to point to anything.
• --no-dev not even sure what this is doing tbh.

Can we just manually delete all the non-semver versions/tags from packagist, add an explanation to the top of the README, and merge develop into master and make master legit (hasn't been updated since August)?

This project is great, but needs a lot of cleanup.

[Rarst]

Ugh, seems the tag was raised from the dead. Thanks for letting us know, I have re-deleted on GitHub and Packagist.

I guess someone might still have it locally and pushed it up? Please make sure you are not doing this for old date tags, @WordPress-Coding-Standards/wpcs-admins @WordPress-Coding-Standards/wpcs-collaborators

create-project can probably be require

You need to have a project for require. Those are instructions for clean from scratch install.

wp-coding-standards/wpcs:dev-master doesn't seem to point to anything.

Could you please elaborate? It points to a master branch.

--no-dev not even sure what this is doing tbh

composer help create-project
--no-dev                         Disables installation of require-dev packages.

and merge develop into master and make master legit

Why? Master is legit as far as I know, it is used for stable releases, as opposed to develop used for ongoing development.

This project is great, but needs a lot of cleanup.

Feedback welcomed, so far I don't follow what warrants change out of these.

[corysimmons]

Thanks for your help @Rarst

Sorry, I thought wpcs:XYZ pointed to the XYZ branch of a project. I didn't realize Composer had "aliases" which add dev- to the front of a branch name.

If anyone wants to require the latest dev-master, they have a problem: Other packages may require 1.0., so requiring that dev version will lead to conflicts, since dev-master does not match the 1.0. constraint.

This part is interesting. Since non-semver versions have been removed now (although it still looks like 2013-10-06 and 2013-06-11 exist), should the instructions simply remove the :dev-master bit?

The last stable release was 46 commits ago? Maybe we could bump this up a bit? WPCS is still pre-1.0.0 so velocity could probably increase without people having a leg to stand on in the "it broke my build" debate (which is somewhat unlikely given it's mostly used to lint). I want bleeeeeding edge WPCS! :D

Sorry if This project is great, but needs a lot of cleanup. seemed a bit snarky. I didn't intend for it to be. I was half-volunteering to contribute docs and such to make integration/usage a bit easier for everyone.

[Rarst]

Sorry, I thought wpcs:XYZ pointed to the XYZ branch of a project

We should probabgly drop dev-master there since Composer these days is intellegent about picking latest available version... Will PR.

although it still looks like 2013-10-06 and 2013-06-11 exist

They don't have composer.json so they don't matter for the issue, Packagist doesn't pick them up.

"it broke my build" debate (which is somewhat unlikely given it's mostly used to lint)

Riiight, it does fail build for me at work and going up a version is quite a challenge both technically and organizationally. Personally I am fine with release pace, but I just hang around here. :)

I want bleeeeeding edge WPCS! :D

Require dev-develop.

[corysimmons]

Require dev-develop

Yeah that's where I landed. I'm fine with release pace as well. Just wanted to nudge in case there were perfectly mergeable things laying around.

Thanks for your updates and helping educate me. 😄