4 ms·

The rule we (rather mature engineer organization) we try to follow is slightly more complex than the one in the post. We run on second to the last version, but

by siscia 6y ago

The rule we (rather mature engineer organization) we try to follow is slightly more complex than the one in the post. We run on second to the last version, but we keep testing on the latest and even beta release. So to catch problems immediately and if possible give our feedback to the developers of the platform.

rkangel 6y ago
Yes, this is the downside of their "use last version" approach - if the version has a regression you can't do anything about it. If you're using the current version then maybe you can have your problem treated as a bug and fixed in a maintenance release.
- sitkack 6y ago
  Your tests also need to execute on the same systems that will run your system. And you need to test on a version back, your version and a version forward. When you move versions, you need to know exactly why and when you lose support for an older platform.
- toast0 6y ago
  I don't think this changes the work involved that much. Either way, you have to investigate the regression and see what changed and why that causes an issue in your environment. It's a little easier to see what change is at issue if you're testing all changes as they come in of course. They got support from upstream, and found out that they also needed to upgrade their environment to support the intended madvise semantics. Maybe if they were tracking master, they could have convinced upstream not to call madvise unless proper semantics were available; maybe not. Sometimes you get lucky and other people find the regressions and the maintenance releases are missing bugs the .0 release had. It's of course nice to check if upstream still has the issue and let them know if so. At the end of the day, if you need code for your system, you need to be able to maintain it. And this post shows they can.
  - siscia 6y ago
    It definitely helps. It de-risk the changes. If you are tracking beta, latest or pre-release you know immediately what is ahead of you. You will know ahead of time, that you will need to investigate this performance regression before to migrate. In a big organizations where resources and time are limited, knowing a bit of what is ahead of you is invaluable.

by siscia 6y ago

rkangel 6y ago

Yes, this is the downside of their "use last version" approach - if the version has a regression you can't do anything about it. If you're using the current version then maybe you can have your problem treated as a bug and fixed in a maintenance release.

sitkack 6y ago
Your tests also need to execute on the same systems that will run your system. And you need to test on a version back, your version and a version forward. When you move versions, you need to know exactly why and when you lose support for an older platform.
toast0 6y ago
I don't think this changes the work involved that much. Either way, you have to investigate the regression and see what changed and why that causes an issue in your environment. It's a little easier to see what change is at issue if you're testing all changes as they come in of course. They got support from upstream, and found out that they also needed to upgrade their environment to support the intended madvise semantics. Maybe if they were tracking master, they could have convinced upstream not to call madvise unless proper semantics were available; maybe not. Sometimes you get lucky and other people find the regressions and the maintenance releases are missing bugs the .0 release had. It's of course nice to check if upstream still has the issue and let them know if so. At the end of the day, if you need code for your system, you need to be able to maintain it. And this post shows they can.
- siscia 6y ago
  It definitely helps. It de-risk the changes. If you are tracking beta, latest or pre-release you know immediately what is ahead of you. You will know ahead of time, that you will need to investigate this performance regression before to migrate. In a big organizations where resources and time are limited, knowing a bit of what is ahead of you is invaluable.