4 ms·

Anyone have advice for teams without control over when their software is deployed by the people actually running it? Say you have a product released to a third

by teeray 3y ago

Anyone have advice for teams without control over when their software is deployed by the people actually running it? Say you have a product released to a third party and they may or may not take releases and may be arbitrarily delayed in deploying those they choose to take.

GrinningFool 3y ago
You're in a for a long tail of pain if you have significant uptake. To avoid this, you will need have a clear policy on what you're willing to support (eg versions up to 1 year old, or "major version - 1", etc.), and stick to it. Otherwise, people will expect you to support all of it, forever.
- hinkley 3y ago
  Bug fix releases never get deployed. If you want people to keep up to date with your releases, you either have to provide an automatic update facility that they have to manually turn off (ugh, too hard), or you have to dangle desirable features as carrots in front of them, so that upgrading is exciting instead of a social obligation.
  - jcrben 3y ago
    My experience is kinda the opposite. Big companies get into certain workflows and don't want to change, altho they are happy to take bugfixes. This is also where I'm at with much of the software I rely upon, some of which I pull at my own whim.
GauntletWizard 3y ago
Give yourself as much leverage as you can get over their deployment cycles. Use both carrot and stick - Include features they can't live without with the hardest of deployment maintenance burdens, and make sure you have tight adherence to your software lifecycle - Every question about 1.0 should be answered with "We don't know, 1.0 is out of support" from the second that it's EOL date passes. Include the currently running version in every logfile, if not every log statement. Make it clear to you where they are and run your own run-behind that upgrades only after they do. This will be painful, but it will save you overall time.
wrsh07 3y ago
If you're talking about an app store you can bundle two binaries in a single binary and then have an external feature flag that selects which binary to use Dealing with the long tail of customers waiting to upgrade will be a persistent challenge though

by teeray 3y ago

GrinningFool 3y ago

You're in a for a long tail of pain if you have significant uptake. To avoid this, you will need have a clear policy on what you're willing to support (eg versions up to 1 year old, or "major version - 1", etc.), and stick to it. Otherwise, people will expect you to support all of it, forever.

hinkley 3y ago
Bug fix releases never get deployed. If you want people to keep up to date with your releases, you either have to provide an automatic update facility that they have to manually turn off (ugh, too hard), or you have to dangle desirable features as carrots in front of them, so that upgrading is exciting instead of a social obligation.
- jcrben 3y ago
  My experience is kinda the opposite. Big companies get into certain workflows and don't want to change, altho they are happy to take bugfixes. This is also where I'm at with much of the software I rely upon, some of which I pull at my own whim.

GauntletWizard 3y ago

Give yourself as much leverage as you can get over their deployment cycles. Use both carrot and stick - Include features they can't live without with the hardest of deployment maintenance burdens, and make sure you have tight adherence to your software lifecycle - Every question about 1.0 should be answered with "We don't know, 1.0 is out of support" from the second that it's EOL date passes. Include the currently running version in every logfile, if not every log statement. Make it clear to you where they are and run your own run-behind that upgrades only after they do. This will be painful, but it will save you overall time.

wrsh07 3y ago

If you're talking about an app store you can bundle two binaries in a single binary and then have an external feature flag that selects which binary to use Dealing with the long tail of customers waiting to upgrade will be a persistent challenge though