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

Tracking issue for Primer v10 #335

Closed
23 of 28 tasks
broccolini opened this issue Sep 1, 2017 · 7 comments
Closed
23 of 28 tasks

Tracking issue for Primer v10 #335

broccolini opened this issue Sep 1, 2017 · 7 comments
Assignees

Comments

@broccolini
Copy link
Member

broccolini commented Sep 1, 2017

Planning to ship Primer v10 in the next couple of weeks, tracking what we'd like to include:

Must

Should

Could

cc @primer/design-systems

@shawnbot
Copy link
Contributor

shawnbot commented Sep 1, 2017

We have a release branch for v10! Here's a proposed plan for managing 9.x changes until we release and merge v10 back to dev:

  1. PRs for 9.x should still be filed against dev.
  2. 10.x changes should merge into release-10.0.0.
  3. If necessary, we can cherry-pick individual merged commits from dev to the v10 release branch.
    • ⚠️ If we do that, we'll need to avoid or revert any changes to version fields in package.json that might unintentionally undo v10 version bumps.

@broccolini
Copy link
Member Author

@shawnbot Just to clarify no. 2. Were you thinking we would branch off of release-10.0.0 or branch off dev and merge into release-10.0.0? There's a couple of in-progress pr's started before this branch, such as the storybook branch but I think we can wrap those up and merge into release-10.0.0 soon. I'm more familiar with the octopus pr approach which would mean all our updates would be branched off `release-10.0.0, reviewed and approved and then merged back in. I think that keeps that branch history cleaner and means in our individual pr's we're testing against all the other changes.

Another thing I was thinking, if I get primer storybook ready it might be good to merge that into release-10.0.0 because it would be handy for testing the updates and additions of new components with and a good way for more of us to test using it.

@shawnbot
Copy link
Contributor

shawnbot commented Sep 5, 2017

Yeah, to clarify: future changes for v10 should branch off release-10.0.0. I'm pretty sure that most, if not all, of the WIP PRs can just have their base changed and work fine as-is. It's the ones that have changes to package.jsons that we'll need to watch out for. I'm no git expert, but changing the base shouldn't muck up the commit history too badly. @jonrohan, do you have any thoughts?

And big 👍 to making Storybook part of the v10 release!

@brandonrosage brandonrosage self-assigned this Sep 13, 2017
@broccolini
Copy link
Member Author

New http://primercss.io/ is live 🎉

@broccolini broccolini mentioned this issue Sep 25, 2017
5 tasks
@broccolini
Copy link
Member Author

@califa @brandonrosage @ampinsk @gladwearefriends @sophshep
Here's a basic outline of what you need to do to test, real docs coming soon!

  1. Make changes in Primer against the dev branch
  2. Test in Storybook by running npm start, you'll need to add a story if there isn't already
  3. When you're happy with the changes you'll need to test in GitHub: make a new branch in github/github, then run bin/npm install primer-css@<your-alpha-release> twice, yes, twice!
  4. At this point you can test locally and make more changes in Primer and repeat step 3 again. If you're happy with your changes, commit your changes, open a pr and deploy to review lab for testing.
  5. If you need to make markup changes in github/github go ahead and do this now and ping @design-systems for review when you're ready.

If you need to test changes in the style guide:

  1. clone the style guide and run script/bootstrap to install all the things
  2. make a new branch and install your alpha release with npm install --save --save-exact primer-css@<your-alpha-release>, then run npm run update-deps,
  3. to run the style guide locally and test your changes, run npm start, (hit ctrl+C to stop the server)
  4. if you want to deploy your branch to share with others, push up your changes and open a pr, join the #design-ops channel and ask hubot to deploy to staging with .deploy styleguide/your-branch to staging

@jonrohan
Copy link
Member

jonrohan commented Nov 2, 2017

twice, yes, twice!

twice so nice 🍦

@broccolini
Copy link
Member Author

This shipped! #354

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

No branches or pull requests

4 participants