Skip to content
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

Ditch gh-pages? #1070

Open
LeaVerou opened this issue Dec 5, 2016 · 16 comments
Open

Ditch gh-pages? #1070

LeaVerou opened this issue Dec 5, 2016 · 16 comments

Comments

@LeaVerou
Copy link
Member

LeaVerou commented Dec 5, 2016

Now that Github supports running Github Pages from master, is there still any reason to have two branches?

@Golmote
Copy link
Contributor

Golmote commented Jan 6, 2017

Probably not. This situation has been confusing for some users in the past, and surely still is.

@LeaVerou
Copy link
Member Author

Is there any info in master that we should retain or is it sufficient to delete the master branch and rename gh-pages to master?

@Golmote
Copy link
Contributor

Golmote commented Jan 28, 2017

I just compared the two branches. There does not seem to be any info in master that is not already in gh-pages (we just did some weird reverting once after an accidental merge of a PR directly on master).

So I think your idea is the way to go ;)

@LeaVerou
Copy link
Member Author

Awesome thanks, will do it in a few days (currently rushing to meet a deadline)!

@mAAdhaTTah
Copy link
Member

@Golmote Can we go ahead with this?

@Golmote
Copy link
Contributor

Golmote commented May 27, 2018

@mAAdhaTTah Having never used Github pages, I must admit I'm not confident at all doing this. I was hoping @LeaVerou would handle it.

Also, I think some people used to reference the gh-pages branch directly. See Bower-related issues #137 (comment), #165 (comment), #180 (comment), #231 (comment), #257 (comment), #497 (comment), and the more recent one using npm #966 (comment). See also this Github search: https://github.com/search?q=%22prism.git%23gh-pages%22&type=Code.
So... will this be considered a breaking change? I'm a bit worried after v1.14's mess.

Finally, we do need to remember we are currently referencing the gh-pages branch in our code too, at least in download.js and in examples.js. We'll need to update all references when making the change.

@mAAdhaTTah
Copy link
Member

Fair enough. I don't really feel strongly that we need to change it. We're working with gh-pages as a "development" branch, with master matching what's on npm, so we can just leave it and go with that approach.

@LeaVerou
Copy link
Member Author

LeaVerou commented May 28, 2018

Sorry for dropping the ball on this 😳
If you decide it's a good idea, I can still do it.
Perhaps we can leave the gh-pages branch intact as an archive to avoid breaking people's code and just start using master for all intents and purposes, including Github Pages?

@Golmote
Copy link
Contributor

Golmote commented May 30, 2018

I like this idea @LeaVerou, that way we don't break anything! 👍

@LeaVerou
Copy link
Member Author

LeaVerou commented Jun 1, 2018

Ok, I just set Github Pages to come from master, and set master as the default branch.
As far as I understand it, we were using gh-pages as a dev branch and publishing releases to master, right?

We need to decide on a few things:

  • Are we going to now use master as a dev branch?
  • If not, are we going to have a separate dev branch? If yes, are we going to have a separate branch for releases, like master used to be?
  • Are we going to keep updating gh-pages or just freeze it in time? What are we going to do with existing PRs that are for gh-pages?

@mAAdhaTTah
Copy link
Member

Sweet!

Are we going to now use master as a dev branch?

I think we should. There's not so much churn / new features in Prism where we need to be able to hotfix off master to release bugfixes while we develop new features on a separate branch.

If yes, are we going to have a separate branch for releases, like master used to be?

I don't think it's necessary, for the same reason. Tagging the branch triggers a release with Travis (I think?), so that should work well.

Are we going to keep updating gh-pages or just freeze it in time? What are we going to do with existing PRs that are for gh-pages?

This, I'm not so sure. For the most part, I expect we could just point those PRs at master without an issue, but a lot of them are fairly stale. I wouldn't feel that bad about just blanket closing them with a note that we'd love to land the changes but they need to updated from master etc.

Alternatively, for the ones we decide we want to include, we could include them "manually", as I did with the tap component–just make the changes ourselves and merge them in to clear out the PRs we have open that we like.

I tried to do a little bit of cleaning of the PRs over the weekend, but the currently-opened ones felt like things we should merge in.

@mAAdhaTTah
Copy link
Member

I think we also need to merge gh-pages -> master?

@Golmote
Copy link
Contributor

Golmote commented Jun 3, 2018

I agree with everything you said. I think we'll use master as the dev branch, use tags to release, and freeze gh-pages. And yes, we need to merge gh-pages into master.

@mAAdhaTTah
Copy link
Member

I'm going to reopen this, as there's still the open question as to what to do with the open PRs pointing @ gh-pages.

@RunDevelopment
Copy link
Member

The are currently no open PRs which point to gh-pages.
So close this and freeze the branch?

@mAAdhaTTah
Copy link
Member

@RunDevelopment Sounds good to me!

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

No branches or pull requests

4 participants