[cweagans]

"Thank you for your inquiry. This is not a service that we offer at this time -- our testing and release process is fully automated and there is not a way for us to exclude some customers and not others.

Can you please help us understand the purpose of the advance notice/release delay is? What benefit does a process like that provide to you or your organization?"

---

I generally use some variation of that ^^. Having some customers on different release tracks is very painful in my experience, especially if it's done without properly planning for it in your release process. For example, let's say that right now, anything committed to `main` goes out to production via some automated process. What happens when you have a security bug that needs dealt with ASAP? In my org, this usually means that the security patch gets rolled out to everyone, and then when it's time for customers on a slower release schedule to "catch up", there are conflicts to resolve manually.

It's just not worth it. Figure out why they're asking, but say no. If it's a problem with buggy releases, that's the _actual_ problem to put some time into solving.

[johncessna]

The argument I always got while trying to argue against delaying features for large customers was that it causes a training headache. If you have large enough customers, redesigning a UI triggers a training initiative for the 100s, if not 1000s of customers that use your software.

[cweagans]

That's a fair concern. There are other ways to address it though. For instance, release the new UI as a "preview" that users can switch to if they want to. If they hate it or can't understand it, they can switch back. Even better: redesign the UI in smaller parts and roll it out slowly over time.