Prism: Ditch gh-pages?

[LeaVerou]

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

[Golmote]

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

[LeaVerou]

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]

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]

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

[mAAdhaTTah]

@Golmote Can we go ahead with this?

[Golmote]

@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 https://github.com/PrismJS/prism/issues/137#issuecomment-21528734, https://github.com/PrismJS/prism/issues/165#issuecomment-47699782, https://github.com/PrismJS/prism/issues/180#issuecomment-28613947, https://github.com/PrismJS/prism/issues/231#issuecomment-48849176, https://github.com/PrismJS/prism/issues/257#issue-34122668, https://github.com/PrismJS/prism/issues/497#issuecomment-83185647, and the more recent one using npm https://github.com/PrismJS/prism/issues/966#issuecomment-379167653. 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]

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]

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]

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

[LeaVerou]

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]

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]

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

[Golmote]

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]

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]

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

[mAAdhaTTah]

@RunDevelopment Sounds good to me!