I think we're fixing the wrong thing here. Instead of changing the docs to match the code, shouldn't we fix the code to match the docs?

Making profile required is a breaking change that forces many developers to update dozens or hundreds of calls. Personally I have 79 revalidateTag() calls, and the original issue mentioned 150.

Most people will just set it to 'max' anyway since it's the recommended value. Can we make profile optional with 'max' as default instead? This would save everyone a lot of unnecessary work.

I think we're fixing the wrong thing here. Instead of changing the docs to match the code, shouldn't we fix the code to match the docs?

Making profile required is a breaking change that forces many developers to update dozens or hundreds of calls. Personally I have 79 revalidateTag() calls, and the original issue mentioned 150.

Most people will just set it to 'max' anyway since it's the recommended value. Can we make profile optional with 'max' as default instead? This would save everyone a lot of unnecessary work.

Yes but no, changing the profile to max also changes the entire behavior of what revalidateTag initially did.

I think we're fixing the wrong thing here. Instead of changing the docs to match the code, shouldn't we fix the code to match the docs?
Making profile required is a breaking change that forces many developers to update dozens or hundreds of calls. Personally I have 79 revalidateTag() calls, and the original issue mentioned 150.
Most people will just set it to 'max' anyway since it's the recommended value. Can we make profile optional with 'max' as default instead? This would save everyone a lot of unnecessary work.

Yes but no, changing the profile to max also changes the entire behavior of what revalidateTag initially did.

My point wasn't really about which default value to use. I said "max" because it's the recommended value in the docs, but that's not the main thing.

But let me ask you this: are you actually okay with this statement being true?

• When using TypeScript, the second argument is required.

I think the intention here has been to get projects using TS to make a choice, to add the second argument where needed, switch to updateTag, or wherever a path forward unclear, ignore the error in some way.

I am actually not sure how I'll tackle this one. The note about supporting only one argument likely needs to be re-worked or presented in a different way. This contradiction is a bit of a headache, but I think the docs should present the one argument signature as a escape hatch that'll trigger TypeScript errors, but work anyway.... Mmm

I think we're fixing the wrong thing here. Instead of changing the docs to match the code, shouldn't we fix the code to match the docs?
Making profile required is a breaking change that forces many developers to update dozens or hundreds of calls. Personally I have 79 revalidateTag() calls, and the original issue mentioned 150.
Most people will just set it to 'max' anyway since it's the recommended value. Can we make profile optional with 'max' as default instead? This would save everyone a lot of unnecessary work.

Yes but no, changing the profile to max also changes the entire behavior of what revalidateTag initially did.

My point wasn't really about which default value to use. I said "max" because it's the recommended value in the docs, but that's not the main thing.

But let me ask you this: are you actually okay with this statement being true?

• When using TypeScript, the second argument is required.

No, I think the second argument should always be required in Next16

Why is it hard to replace all to updateTag? I mean you're doing a major upgrade, a breaking change like this is expected?

Setting the default to {expire: 0} would keep the Next15 behavior, but it's not the recommended value so doesn't make sense.