The ultimate SemVer discussion: how?

[SammyK]

You heard it on PHP Roundtable first ladies and gentlemen! Straight from the horse's mouth, @gfosco is open to supporting SemVer! Yay! :D

But! The question is: how?

The current repo is prefixed with -v4. I know we can rename, but GitHub doesn't support 301 redirects which can be problematic for all the links pointing to this repo. But once it's renamed, it should be pretty trivial (I think) to point packagist to the new repo & people can still use composer like they've always done.

Anyone ever done this before & have advice on how we can rename the repo without too much disruption? :) cc @yguedidi @mtdowling

Yay for 5.0! :D

[yguedidi]

Sorry, quick answer:

• GitHub supports renaming with redirect
• about Packagist, a today tweet !!
• but facebook/php-sdk already abandonned on Packagist, it should be resurrected (or deleted and recreated) :)

Note: Following SemVer doesn't mean we have to start from scratch or from a major version. We can assume (and document) that we start following SemVer from 4.1.

PS: @gfosco, thanks for mentioning me in the last Roundtable! :)
PPS: @SammyK I'll correct you as usual: the current repo is suffixed, not prefixed :p

[SammyK]

Nice! So it actually might be easier than I thought!

Following SemVer doesn't mean we have to start from scratch or from a major version. We can assume (and document) that we start following SemVer from 4.1.

True. I've been doing a lot of talks/blogs about 4.1 being a complete rewrite, but I think it'd be better to just market this as 5.0 from now on so that future developers won't need the same "here's our SemVer history for why things are all versioned strangely". :) Laravel had the same issue where they were talking about 4.3 for a long time and at last minute they changed it to 5.0. Sigh... the joys of being a developer. :)

@yguedidi When you get more time, can you provide specific steps for @gfosco to get master rocking as 5.0? :)

the current repo is suffixed, not prefixed :p

Ha! Indeed it is... :)

but facebook/php-sdk already abandonned on Packagist, it should be resurrected (or deleted and recreated) :)

Good point. I think it might be confusing to resurrect it. Maybe we just alias the new SemVer package as facebook/sdk? We don't really need the php- suffix since packagist isn't going to have anything other than PHP anyways. :)

[SammyK]

PS @yguedidi One of these days I'm going to get you on the Roundtable! :)

[SammyK]

@gfosco Do you want to go ahead and start marketing 4.1 as 5.0? Highly recommended! :) If so I'll update the docs, etc.

[gfosco]

Yeah.... Let's do it. 5.0. It'll take a little longer to get out, but we'll figure out all the renaming and whatever else.

[SammyK]

W00t! ... And now to go back through months of blogs/docs and update the version number. Lol.

[yguedidi]

Hooray! @gfosco you made my day!

We have to be sure about how to rename this repo/packagist/etc...
One cool thing would be to check again the whole public API of the SDK, I'll try to help once I'll have some time.

PS: @SammyK haha maybe once I release my SDK (which is currently more like a vaporware...), but you'll need to speak sooo slowly and a live voice translator for my french-flavored english :)

[SammyK]

We have to be sure about how to rename this repo/packagist/etc...

@yguedidi Is there a way we can alias both 4.1.0@dev & 5.0@dev to the master branch in the composer.json?

maybe once I release my SDK

Deal! :)

[yguedidi]

@SammyK according those lines in Composer, we can't...

[yguedidi]

A solution would be to create a real branch 4.1.x-dev, and periodically (or not) merge master in it, but I don't like that solution...

[SammyK]

How's about we create a 5.x-dev branch with the current master.

Then, in master, we update the composer.json to have:

        "branch-alias": {
            "dev-master": "5.x-dev"
        }

And in the 5.x-dev branch, we have:

        "branch-alias": {
            "4.1.x-dev": "5.x-dev"
        }

And we can keep the branch alias in the 5.x-dev branch even after it's been tagged as stable so all the requires for 4.1.0@dev will still work and just pull from the 5.x-dev branch.

Would that work? I'm not familiar with the branch-alias stuff enough to really know what's going on. Lol. :)

[yguedidi]

@SammyK branch aliasing is useless when the real branch exists.

I suggest to create a 4.1.x-dev branch based on current master for all developers which currently require ~4.1.0@dev to not break their installed vendor (especially for ones that will newly install the SDK, already installed SDK are referenced by commit id thanks to the composer.lock).

Then, we can alias master as our 5.x-dev branch.

@gfosco, you can optionally rebase the 4.1.x-dev branch on master periodically, but I'd prefer to warn people using ~4.1.0@dev that they will not get any update and they are encouraged to require ~5.0@dev instead.
Then once the 4.1.x-dev branch get zero monthly downloads on Packagist, @gfosco (you again lol) can safely remove that branch.

PS: about removing branch @gfosco can you remove the old gFosco.graph-v2.2 branch?

[gfosco]

Ok... I created a branch 4.1-dev based on current master, and removed the gFosco.graph-v2.2 branch.

What's next?

I'm getting close to getting approval to launching docs on github... but we'll have to convert all the XHP table widgets to standard markdown :\

[devmsh]

Can I offer any help about the XHP issue?

Please clarify what is the required medications, and I will help on that

[yguedidi]

@gfosco I made a mistake... According this function of Composer, branches can just be named 4.0 and 4.1 (or 4.0.x and 4.1.x, as you prefer).

Then:

• a PR on 4.1 to remove composer aliasing
• PRs on master that change the branch aliasing and update occurrences of 4.1 to 5.0

[yguedidi]

I'll do more research about renaming this repo, I do not have the time now.

[SammyK]

According this function of Composer, branches can just be named 4.0 and 4.1

@yguedidi Yes, but as far as I can tell it's being regexed before it gets sent to that method.

I just called upon the twittersphere for help on this one. :)

I'm getting close to getting approval to launching docs on github...

@gfosco Yay!!!!! Does that mean the developer site will just link to the GitHub version? And do you mean a GitHub static site or a wiki on the repo?

but we'll have to convert all the XHP table widgets to standard markdown :\

That's cool. I can work on that after I update the docs to refer to 5.0. :)

[stof]

@SammyK regarding the 301 redirects on Github, they are indeed doing it for repo renamings on the web. For the API (which include the download URLs used by Composer in its lock file), this should be supported in a few months (it is currently in preview but composer does not use the preview accept header): https://developer.github.com/changes/2015-04-17-preview-repository-redirects/

[SammyK]

Thanks for the info @stof!

@yguedidi @gfosco Until GitHub rolls out the 301's, can we just keep the repo name as-is? We should be able to change it on packagist still, right? And then when the 301 feature is rolled out, we can rename the repo?

[gfosco]

Ok, I'm okay with that for now.

[gfosco]

So yeah, we're going live with the awkward v4 name for now. Closing this.

[SammyK]

I think the composer require line...

"facebook/php-sdk-v4": "~5.0"

...is totes adorbs. :)

[hassankhan]

Hi, just so you know, the 301's seem to be working (or at least, are working for me)

[redstrike]

It has been a year since this issue was closed. I wonder when this issue will be solved completely?

I am an all-new FB PHP SDK user who is trying to install the latest stable version and the awkward name of this repo costs me time to research "Why?" :(