docs: WebViewAttributes stability

[Legend-Master]

Mainly copied in the one we had for tauri config

Looking at the patch version we just released, #1649 is technically breaking since we added a field to WebViewAttributes with all pub fields

[github-actions]

Package Changes Through f851882

There are 1 changes which include wry with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
wry	0.54.3	0.54.4

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[Legend-Master]

Seems like drag_drop_handler is marked non pub when drag-drop feature is disabled, I wonder if we should still keep this feature flag, like all the implementations are not gated by the feature flag, only the entry point (WebViewAttributes::drag_drop_handler and WebViewBuilder::with_drag_drop_handler) are

We should either remove the flag or properly gate the implementations

[pewsheen]

Seems like drag_drop_handler is marked non pub when drag-drop feature is disabled, I wonder if we should still keep this feature flag, like all the implementations are not gated by the feature flag, only the entry point (WebViewAttributes::drag_drop_handler and WebViewBuilder::with_drag_drop_handler) are

We should either remove the flag or properly gate the implementations

Sounds reasonable to me. @amrbashir Do you remember why drag-and-drop needs to be guarded?

[amrbashir]

I think it was done so users won't see the field if they didn't enable the feature flag, but it shouldn't matter either way

[FabianLars]

marking the struct as non_exhaustive would be too annoying to use right?

wondering if it makes sense to have stability docs like this in a 0.x library instead of adding a semver ci check that helps prevent us breaking it in a patch.

and if we were to release wry v1 i'd assume a builder pattern or whatever instead of an unstable struct would be used.

[Legend-Master]

marking the struct as non_exhaustive would be too annoying to use right?

You can't construct a non_exhaustive struct directly?

I think even we're on 0.x, a breaking change still requires everything depending on it to upgrade and without a notice like this, almost any new features will be 'breaking' while nothing's actually breaking

Alternatively, remove it from the public APIs, the builder should fully cover its use cases except for maybe getting data out the builder

[FabianLars]

You can't construct a non_exhaustive struct directly?

lol

I think even we're on 0.x, a breaking change still requires everything depending on it to upgrade and without a notice like this, almost any new features will be 'breaking' while nothing's actually breaking

yeah but if devs have to lock the patch versions cause they're breaking why do we even use semver?

Alternatively, remove it from the public APIs, the builder should fully cover its use cases except for maybe getting data out the builder

I would not mind that at all! If not even tauri uses the struct, who does?