Bump `FormatProps` to `@public`

[GerardasB]

This PR changes the release tag of FormatProps to @public. To address https://github.com/iTwin/appui/issues/891

[ColinKerr]

@rschili please review this in the context of your current work to extend formats supported.

I believe this should be OK because format props are somewhat tied to EC's format specification which is already locked down

[rschili]

@rschili please review this in the context of your current work to extend formats supported.

I believe this should be OK because format props are somewhat tied to EC's format specification which is already locked down

Looks good to me.

[rschili]

Hey, I just discussed this with @ColinKerr . We're currently actively making changes to that interface. They will 99% not be breaking changes, so making this public should be fine, however, if there is no strong need to merge this right now, we would like to hold this off for 2 weeks until we have the final version of the interface, just to be safe.

[pmconne]

Hey, I just discussed this with @ColinKerr . We're currently actively making changes to that interface. They will 99% not be breaking changes, so making this public should be fine, however, if there is no strong need to merge this right now, we would like to hold this off for 2 weeks until we have the final version of the interface, just to be safe.

That's fine. Are you, @ColinKerr, or anyone else looking more generally into the quantity formatting and units APIs? They've been stuck in alpha/beta for years, people have been using them anyway, and we need a plan to stabilize and properly document them.

[rschili]

That's fine. Are you, @ColinKerr, or anyone else looking more generally into the quantity formatting and units APIs? They've been stuck in alpha/beta for years, people have been using them anyway, and we need a plan to stabilize and properly document them.

@pmconne I'm afraid not, I'm just doing a few very specific things for Booster (Bearing angles, Azimuth angles, ratio and alternative labels). But as I understand, @anmolshres98 and possible Nam Le are intended to take over ownership for the quantity things soon.

[anmolshres98]

That's fine. Are you, @ColinKerr, or anyone else looking more generally into the quantity formatting and units APIs? They've been stuck in alpha/beta for years, people have been using them anyway, and we need a plan to stabilize and properly document them.

@pmconne I'm afraid not, I'm just doing a few very specific things for Booster (Bearing angles, Azimuth angles, ratio and alternative labels). But as I understand, @anmolshres98 and possible Nam Le are intended to take over ownership for the quantity things soon.

yes, I and @hl662 plan to take this pkg over

[hl662]

That's fine. Are you, @ColinKerr, or anyone else looking more generally into the quantity formatting and units APIs? They've been stuck in alpha/beta for years, people have been using them anyway, and we need a plan to stabilize and properly document them.

In light of this and other PRs recently that's expected to contribute to core-quantity, we can review the existing Quantity Formatting learnings documentation. We can also look over the .md for core-quantity api and go over anything that is marked as undocumented.

Paul, are you looking for improvements into the documentation for the consumers of the API, or the developers contributing to the API? This could be one and the same too.

[mergify[bot]]

This pull request is now in conflicts. Could you fix it @GerardasB? 🙏 To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

[pmconne]

Paul, are you looking for improvements into the documentation for the consumers of the API, or the developers contributing to the API? This could be one and the same too.

Consumers first and foremost.

[GerardasB]

That's fine. Are you, @ColinKerr, or anyone else looking more generally into the quantity formatting and units APIs? They've been stuck in alpha/beta for years, people have been using them anyway, and we need a plan to stabilize and properly document them.

@pmconne Given the @alpha/@beta situation in core packages and the fact that we have committed to keeping those APIs stable, would it make sense to change them ALL to @public instead of going 1 by 1?

[pmconne]

Given the @alpha/@beta situation in core packages and the fact that we have committed to keeping those APIs stable, would it make sense to change them ALL to @public instead of going 1 by 1?

@GerardasB can you clarify what you mean by "we have committed to keeping those APIs stable"?

[GerardasB]

@GerardasB can you clarify what you mean by "we have committed to keeping those APIs stable"?

My assumption is based on this commitment/exception to avoid breaking the internal APIs: https://github.com/iTwin/itwinjs-core/blob/2abffabee0774d742d3848fad9f2c2f6faf37b16/docs/changehistory/NextVersion.md?plain=1#L39 I assumed we want to avoid breaking APIs marked @alpha or @beta as well, especially those that have existed for some time (i.e. longer than 6 months?).

EDIT: on second thought there might be a good reason to keep those existing APIs @beta - it's to indicate to other consumers that the API is "not stable" and should be avoided, even if we treat it as stable (no breaking-changes allowed). It gives us more time to validate and mark it public or deprecate/propose a replacement.