-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Elevate BackendHubAccess to public, remove deprecated 3.x APIs in core-backend #7587
base: master
Are you sure you want to change the base?
Conversation
export interface BackendHubAccess { | ||
// @internal | ||
acquireLocks: (arg: BriefcaseDbArg, locks: LockMap) => Promise<void>; | ||
acquireNewBriefcaseId: (arg: AcquireNewBriefcaseIdArg) => Promise<BriefcaseId>; | ||
createNewIModel: (arg: CreateNewIModelProps) => Promise<GuidString>; | ||
deleteIModel: (arg: IModelIdArg & ITwinIdArg) => Promise<void>; | ||
downloadChangeset: (arg: DownloadChangesetArg) => Promise<ChangesetFileProps>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GytisCepk I ran extract-api and it threw warnings for 2 methods, saying it uses args (DownloadChangesetArg
and DownloadChangesetRangeArg
) that are marked as @beta for this API I just converted to @public... git blame showed you most recently worked on this, do you think those args are okay to move to public or should we move BackendHubAccess
to @beta instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect DownloadChangesetRangeArg
to break due to #7357. So we might mark it @public
to just deprecate it soon after.
That being said, if there is no other concerns about making BackendHubAccess
public, I would go ahead and mark both DownloadChangesetArg
and DownloadChangesetRangeArg
public.
public
BackendHubAccess
interface topublic
Notes:
TODO: