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

Lock internal dependencies to patch version #656

Merged
merged 2 commits into from
Nov 27, 2018
Merged

Lock internal dependencies to patch version #656

merged 2 commits into from
Nov 27, 2018

Conversation

benbrown
Copy link
Contributor

Fixes #652

Description

Update all the package files to change dependency on other Botbuilder libraries from any minor release (^4.0.0) to the specific minor release (~4.1.x)

This means a user installing version 4.1.7 will get all 4.1 updates, but will not automatically migrate to 4.2 which could break things.

@coveralls
Copy link

coveralls commented Nov 21, 2018

Pull Request Test Coverage Report for Build 2242

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.06%) to 82.098%

Files with Coverage Reduction New Missed Lines %
libraries/botframework-config/src/botConfigurationBase.ts 2 85.59%
Totals Coverage Status
Change from base Build 2240: -0.06%
Covered Lines: 2633
Relevant Lines: 3088

💛 - Coveralls

Copy link
Member

@stevengum stevengum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @benbrown, we leave these versions at 4.0.0 because we automatically bump the version numbers via this script which is run in the .travis.yml file via npm update-versions. I think we just need to change the internal dependencies from using "^" to "~".

@cleemullins /@JuanAr am I correct in my statements?

@benbrown
Copy link
Contributor Author

@stevengum yes, we do update them as part of the build.

After consulting with @cleemullins I updated the versions on Github because I thought it better to have working internal consistency -- IE, how can we be pointing to ~4.1.6 if on Github the package file says the current version is 4.0.0?

IMHO we should keep the public record clean and consistent.

@stevengum
Copy link
Member

I'm all for keeping the public record clean and consistent as long as we stay consistent going forward 😄

:shipit:!

@benbrown
Copy link
Contributor Author

@stevengum I have made an informal suggestion that we put together a shipping checklist that we run through every time we publish a new version that would include maintenance tasks like this! I will make roll up my sleeves and just do it soon.

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

Successfully merging this pull request may close these issues.

4 participants