Stricter API guarantees for non experimental APIs

[yschimke]

I don't think RoborazziOptions and CompareOptions are marked as experimental, but the change in a506133#diff-9012f191f9216650ef0280cd21cf411514ed71502bdf5e2d122ffcb60be7727eR99 broke binary compatibility.

Should these be considered and marked experimental?

Or should roborazzi support some compatibility story?

This is not a major issue, just flagging for discussion and guidance.

[takahirom]

Thanks. Yes, it would be a breaking change for binary compatibility, but it’s challenging to balance speed and compatibility. I’m not sure if there are any libraries currently using Roborazzi’s APIs. For now, I'm waiting for the dataarg class to help maintain compatibility. After that, I think we can introduce a validator, though I don’t have a strong opinion on it. If anyone is affected by compatibility issues with this library, I’d like to address it.
https://medium.com/@omarsahl/kotlin-language-features-from-kotlinconf-2024-whats-new-and-what-s-next-a4668eae5e9d

[yschimke]

Horologist publishes a library but probably only used by a small handful of apps. So issue isn't wide. But it's why I found it.

[takahirom]

I learned that dataarg isn't even in Kotlin KEEP, so it may take a long time to be released. We might have to consider the builder pattern or something similar. 💭 It could cause significant API changes. If we proceed with this, it would be Roborazzi 2.0 or something.

[takahirom]

If anyone is using Roborazzi for an internal library or something similar and is experiencing issues with binary compatibility, please let me know. I would like to prioritize addressing this issue.

[colinrtwhite]

Preserving binary compatibility data class is hard to maintain. Using a builder pattern like you mentioned or using Poko and manually defining secondary constructors and copy functions and deprecating them when a new argument is introduced would also work. For the builder pattern you could always create a DSL like Ktor uses if preferred:

RoborazziOptions {
  aiOptions {
     prompt("prompt")
  }
}

I'd probably not wait for dataarg support as it might not ever arrive in Kotlin. I'm still waiting on namespaces!