# 1.0 ergonomic API surface
Status: implemented
## Problem
The pre-1.0 public surface had inconsistent setter vocabulary, dependency types
leaking through error variants, owned-return accessors, and structs that could not
gain fields without a break. The 1.0 breaking window was the only chance to clean
these up together.
## Decision
The following landed as one coordinated 1.0 surface.
- Unified custom-endpoint setter `url()` across all git backends (github already had
it; gitlab and gitea moved off `instance_url`).
- Opaque boxed error wrapper variants. `Http`, `S3Auth`, `Zip`, `Signature`, `Json`,
and `SemVer` each wrap `Box<dyn std::error::Error + Send + Sync>` instead of the
concrete dependency type; the inner error stays reachable via `Error::source()` or
a downcast. `Error::NonUTF8` is renamed `Error::SignatureNonUTF8` (signatures
feature). `Error` is `#[non_exhaustive]`.
- Predicate pair `is_up_to_date()` / `is_updated()` on `Status` and `UpdateStatus`
(renamed from `uptodate()` / `updated()`).
- `bin_install_path()` returns `&Path` (was an owned `PathBuf`), matching the other
borrowing accessors.
- `#[non_exhaustive]` on the utility structs (`Download`, `Extract`, `Move`,
`MoveAll`) and the per-backend concrete `Update` / `custom::AsyncUpdate` structs.
- Generic `Download::header()` taking `TryInto<HeaderName>` / `TryInto<HeaderValue>`
and returning a `Result`, matching the builder `request_header()`.
- `DEFAULT_PROGRESS_TEMPLATE` / `DEFAULT_PROGRESS_CHARS` demoted to `pub(crate)` (they
baked indicatif syntax into the contract).
- `backends::custom::Blocking`'s field is private with `new` / `into_inner` /
`as_inner` accessors.
- `AsyncReleaseSource` futures are required to be `Send` at the type level (returned
`impl Future<Output = ...> + Send`), so a non-`Send` impl fails at the impl site
rather than later at the spawn site, with no `async-trait` / `trait_variant`
dependency.
- The accessor getters moved to a sealed `UpdateConfig` supertrait
(`ReleaseUpdate: UpdateConfig`), leaving `ReleaseUpdate` with the three fetches plus
`update` / `update_extended`.
The fetch-once `Releases` check type is its own spec (see `releases-check-type.md`).
See `src/errors.rs`, `src/update.rs`, `src/lib.rs`, `src/backends/`, and the CHANGELOG
`[1.0.0]` and `[unreleased]` Changed entries plus the migration guides.