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

CHORE - Once we go RC or Stable, set main branch back to master #335

Closed
khawkins98 opened this issue Apr 1, 2019 · 3 comments
Closed

CHORE - Once we go RC or Stable, set main branch back to master #335

khawkins98 opened this issue Apr 1, 2019 · 3 comments

Comments

@khawkins98
Copy link
Contributor

Once we go to beta we'll need to ship CSS less often for the EMBL sites and we'll want to show a more stable look, so it makes sense to set the default branch back to master.

Thoughts/considerations:

  • We should make the change just after we PR edits for beta.1 from develop -> master
  • Shouldn't impact the gitlab-ci setup (develop branch commits still go to dev deploy)
  • Travis will still deploy gh-pages on commits to dev
  • If we want to change the way that travis or gitlab are running, we'll have to pull those changes in from develop
@khawkins98 khawkins98 added this to the v2.0.0-beta.1 milestone Apr 1, 2019
@khawkins98 khawkins98 mentioned this issue Apr 1, 2019
8 tasks
@sturobson sturobson added this to to do in VF v2.0.0-beta.1 Jun 5, 2019
@khawkins98
Copy link
Contributor Author

Thinking on this a bit more, maybe we hold off:

  1. We have more important things to do
  2. I guess as we're still not stable/rc, it's fair for develop to be the main branch

@khawkins98 khawkins98 changed the title CHORE - Once we go beta, set main branch back to master CHORE - Once we go RC or Stable, set main branch back to master Aug 8, 2019
@khawkins98 khawkins98 removed this from the v2.0.0-beta.4 milestone Oct 7, 2019
@khawkins98
Copy link
Contributor Author

khawkins98 commented Dec 20, 2019

Had a fresh look at this one now that we're at RC; here's what I suggest we do:

  1. Delete the current master branch as it's very stale
  2. Make a new master branch based off the current develop
  3. Set the main branch to master
  4. Tag future release to the master branch

There may be other things we want to do, but i think that should be enough to "Use master for stable releases"

@khawkins98
Copy link
Contributor Author

Did some more reading and it makes sense to keep the default branch as develop mostly as all PR will target that branch by default, and that's where we want our PR going -- otherwise I think we'll accidently merge stuff to master and then have to PR master --> develop 😭

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

No branches or pull requests

1 participant