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

Document release process (differences between 1.x-stable and 2.x-experimental) #270

Closed
annekainicUSDS opened this issue Sep 17, 2018 · 5 comments
Assignees
Labels
[practice] engineering Engineering related work [practice] product Product related work

Comments

@annekainicUSDS
Copy link
Contributor

We need to come up with a better solution for releasing patches for bug fixes quickly, and group breaking changes in chunks and release those more slowly. Our current release process does not enable us to do this.

@annekainicUSDS annekainicUSDS added [practice] engineering Engineering related work [practice] product Product related work labels Sep 17, 2018
@annekainicUSDS
Copy link
Contributor Author

Notes from conversation with Vets.gov team:

  • The main breaking changes (definitions and analytics) are not a big lift for them to upgrade to (they want to be making changes to the analytics now anyway)
  • Not sure yet about the routing changes what the lift will be until they see the changes
  • General goals: they want breaking changes to come slowly (~4-6 weeks) and in large chunks so they can plan around them, while bug fixes to be made immediately
  • They want to stay up to date as much as possible
  • We can agree on some set expectations (e.g., not merging patches on a release that is 2-3 major releases ago)
  • One potential solution is pushing breaking changes to a separate branch before they get released so that patches can still be made to master and released more quickly (this will be easier to implement going forward, but may be trickier to go backwards and do because breaking changes have already been merged to master, but we could create a branch from a patch and move those commits over to that branch and release those as a patch)

@jcmeloni-usds jcmeloni-usds self-assigned this Sep 19, 2018
@jcmeloni-usds
Copy link
Contributor

Assigned to myself to review and comment. Putting in Phase II.

@annekainicUSDS
Copy link
Contributor Author

One thing we may need to revisit when looking at the release process is our CircleCI config, which deploys only the "production" branch. If we change our branching strategy, this config may need to change.

@jcmeloni-usds
Copy link
Contributor

jcmeloni-usds commented Oct 3, 2018

Dave has been keeping wiki page up to date so we'll call this good.

The team will continually work / ongoing work to refine the process and so on.

@jcmeloni-usds jcmeloni-usds changed the title New release process Document release process (differences between 1.x-stable and 2.x-experimental) Oct 3, 2018
@jcmeloni-usds
Copy link
Contributor

Closing this because of the previous comment, and also because there isn't an experimental branch yet. but pleae promise when you get there, you'll document the differences. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[practice] engineering Engineering related work [practice] product Product related work
Projects
None yet
Development

No branches or pull requests

2 participants