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

How do we want to approach updating modules? #104

Open
abea opened this issue Dec 19, 2017 · 5 comments
Open

How do we want to approach updating modules? #104

abea opened this issue Dec 19, 2017 · 5 comments
Labels

Comments

@abea
Copy link

abea commented Dec 19, 2017

Post-launch, if updating a module isn't necessary to fix a particular issue or add a new feature, when, if ever, should we npm update?

@abea abea added the Question label Dec 19, 2017
@abea
Copy link
Author

abea commented Dec 19, 2017

My understanding is that this should not be done if there's no particular need to avoid unexpected effects.

@bobclewell
Copy link
Contributor

bobclewell commented Dec 19, 2017

Agreed.

Moreover, to insure that even running npm update doesn't do anything you should specify the exact version on all your dependencies before going to production in package.json. E.g.

"apostrophe-blog": "2.0.2"

versus

"apostrophe-blog": "^2.0.2"

@boutell
Copy link
Member

boutell commented Dec 19, 2017

I disagree that we should not npm update projects to the latest versions of apostrophe, apostrophe-blog, etc. routinely when updating them.

Once we start making exceptions to that we are going to get into places where people are working around crap forever and not seeing the apostrophe update process as something that's for them and their projects, IMHO. And "I want that fix but I'm afraid of the 20 minor versions I skipped and what they might do."

We have strong practices around avoiding bc breaks and regressions in the core modules. And we can get stricter about that if we have to, I'd prefer that to projects being "pinned" ever, possibly excepting very tetchy clients with very risky needs.

My 2 cents.

@abea
Copy link
Author

abea commented Dec 19, 2017

That make sense. I'd be more concerned about updating modules that we don't maintain. If modules are well maintained and take care of specifying dependency versions where necessary it's not a problem. Can we rely on that?

@boutell
Copy link
Member

boutell commented Dec 19, 2017

That's a good question. There's a tension between the risk of instability due to poor choices on the part of third party maintainers, and the risk of bugs and security holes due to not paying any mind to updates from third party maintainers. I think security holes are the bigger danger (I'm never, ever, ever going to try to track them on my own across hundreds of modules, nobody is). Which is why I think we should be updating third party modules via the usual semver setup, and pushing our CI plans for client projects forward ASAP.

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

No branches or pull requests

3 participants