4 ms·

Just this morning I've spent an hour trying to get a well-known Http library to work in my project, cos the developers keep completely refactoring all the class

Just this morning I've spent an hour trying to get a well-known Http library to work in my project, cos the developers keep completely refactoring all the classes and methods. Stop it!!

Ididntdothis 7y ago
But how do you want to avoid that? Staying with old libraries forever? In some areas this is possible but in others you have to use newer stuff. I always envy people who work on stuff that’s mainly their own code and not cobbled together from other systems with their questionable APIs.
- Crinus 7y ago
  > But how do you want to avoid that? Staying with old libraries forever? Well, one way would be those libraries to have backwards compatible APIs so that your code keeps working yet still using the same APIs. Some actually do try that (or at least they claim so), e.g. curl.
danesparza 7y ago
The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready
- Ididntdothis 7y ago
  Until your CI pipeline causes churn because something doesn’t work anymore....
  - umvi 7y ago
    We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).
    - pritianka 7y ago
      What an awesome compliment for our team. Thank you!
  - danesparza 7y ago
    Your CI pipeline should be simple, relatively unchanging and therefore trusted. When shit breaks (and it will) you should get a signal much earlier. This signal should strongly relate to your most recent changes -- and your changes should be small because you commit early and often, right?
    - xemdetia 7y ago
      Some of us deal with the fact that the people maintaining the CI solution keep breaking our pipelines without any code changes in of our scope of responsibility. This becomes the churn as you push empty commits trying to troubleshoot why your builds don't work and it takes >1 day to get things working again. Most hosted CI solutions are entirely inappropriate for some organization's business goals and requirements, so you end up dealing with it being a B or C tier service in an organization that is changing. I would suggest that there are definitely some organizations where you can't trust the pipeline to work reliably, and the cost of figuring out what went wrong becomes the churn.
- tonyedgecombe 7y ago
  The problem is you don't have CI Having CI won't stop the developer of the dependency changing the interface.
  - mffnbs 7y ago
    Why are developers mindlessly upgrading major versions of dependencies and expecting everything to be okay?
dmux 7y ago
Are you able to program against an interface rather than the classes themselves or is the entire API changing?
rootlocus 7y ago
A breaking change in API should mean a major version bump. You're either not using the public API, using the 'latest' version, or the library is, pardon my french, poop.

Just this morning I've spent an hour trying to get a well-known Http library to work in my project, cos the developers keep completely refactoring all the classes and methods. Stop it!!

Ididntdothis 7y ago

But how do you want to avoid that? Staying with old libraries forever? In some areas this is possible but in others you have to use newer stuff. I always envy people who work on stuff that’s mainly their own code and not cobbled together from other systems with their questionable APIs.

Crinus 7y ago
> But how do you want to avoid that? Staying with old libraries forever? Well, one way would be those libraries to have backwards compatible APIs so that your code keeps working yet still using the same APIs. Some actually do try that (or at least they claim so), e.g. curl.

danesparza 7y ago

The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready

Ididntdothis 7y ago
Until your CI pipeline causes churn because something doesn’t work anymore....
- umvi 7y ago
  We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).
  - pritianka 7y ago
    What an awesome compliment for our team. Thank you!
- danesparza 7y ago
  Your CI pipeline should be simple, relatively unchanging and therefore trusted. When shit breaks (and it will) you should get a signal much earlier. This signal should strongly relate to your most recent changes -- and your changes should be small because you commit early and often, right?
  - xemdetia 7y ago
    Some of us deal with the fact that the people maintaining the CI solution keep breaking our pipelines without any code changes in of our scope of responsibility. This becomes the churn as you push empty commits trying to troubleshoot why your builds don't work and it takes >1 day to get things working again. Most hosted CI solutions are entirely inappropriate for some organization's business goals and requirements, so you end up dealing with it being a B or C tier service in an organization that is changing. I would suggest that there are definitely some organizations where you can't trust the pipeline to work reliably, and the cost of figuring out what went wrong becomes the churn.
tonyedgecombe 7y ago
The problem is you don't have CI Having CI won't stop the developer of the dependency changing the interface.
- mffnbs 7y ago
  Why are developers mindlessly upgrading major versions of dependencies and expecting everything to be okay?

dmux 7y ago

Are you able to program against an interface rather than the classes themselves or is the entire API changing?

rootlocus 7y ago

A breaking change in API should mean a major version bump. You're either not using the public API, using the 'latest' version, or the library is, pardon my french, poop.