New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The ultimate SemVer discussion: how? #411

Closed
SammyK opened this Issue Apr 24, 2015 · 24 comments

Comments

Projects
None yet
7 participants
@SammyK
Collaborator

SammyK commented Apr 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi Apr 24, 2015

Collaborator

Sorry, quick answer:

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

Collaborator

yguedidi commented Apr 24, 2015

Sorry, quick answer:

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

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK Apr 24, 2015

Collaborator

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

Collaborator

SammyK commented Apr 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK Apr 24, 2015

Collaborator

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

Collaborator

SammyK commented Apr 24, 2015

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

@SammyK

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK Apr 29, 2015

Collaborator

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

Collaborator

SammyK commented Apr 29, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@gfosco

gfosco Apr 29, 2015

Contributor

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.

Contributor

gfosco commented Apr 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK Apr 29, 2015

Collaborator

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

Collaborator

SammyK commented Apr 29, 2015

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

@yguedidi

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi Apr 29, 2015

Collaborator

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

Collaborator

yguedidi commented Apr 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK Apr 30, 2015

Collaborator

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! :)

Collaborator

SammyK commented Apr 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi Apr 30, 2015

Collaborator

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

Collaborator

yguedidi commented Apr 30, 2015

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

@yguedidi

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi Apr 30, 2015

Collaborator

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

Collaborator

yguedidi commented Apr 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK May 1, 2015

Collaborator

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

Collaborator

SammyK commented May 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi May 4, 2015

Collaborator

@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?

Collaborator

yguedidi commented May 4, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@gfosco

gfosco May 4, 2015

Contributor

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 :\

Contributor

gfosco commented May 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@devmsh

devmsh May 5, 2015

Contributor

Can I offer any help about the XHP issue?

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

Contributor

devmsh commented May 5, 2015

Can I offer any help about the XHP issue?

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

@yguedidi

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi May 5, 2015

Collaborator

@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
Collaborator

yguedidi commented May 5, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@yguedidi

yguedidi May 5, 2015

Collaborator

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

Collaborator

yguedidi commented May 5, 2015

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

@SammyK

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK May 5, 2015

Collaborator

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

Collaborator

SammyK commented May 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stof

stof May 5, 2015

@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/

stof commented May 5, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK May 6, 2015

Collaborator

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?

Collaborator

SammyK commented May 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gfosco

gfosco May 8, 2015

Contributor

Ok, I'm okay with that for now.

Contributor

gfosco commented May 8, 2015

Ok, I'm okay with that for now.

@gfosco

This comment has been minimized.

Show comment
Hide comment
@gfosco

gfosco Jul 8, 2015

Contributor

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

Contributor

gfosco commented Jul 8, 2015

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

@gfosco gfosco closed this Jul 8, 2015

@SammyK

This comment has been minimized.

Show comment
Hide comment
@SammyK

SammyK Jul 8, 2015

Collaborator

I think the composer require line...

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

...is totes adorbs. :)

Collaborator

SammyK commented Jul 8, 2015

I think the composer require line...

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

...is totes adorbs. :)

@hassankhan

This comment has been minimized.

Show comment
Hide comment
@hassankhan

hassankhan Dec 15, 2015

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

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

@redstrike

This comment has been minimized.

Show comment
Hide comment
@redstrike

redstrike Jun 24, 2016

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?" :(

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?" :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment