#10

I also would be in favor of an unstable beta API.

One thing I would appreciate is having the documentation be clear about the stability level of each API call. e.g. have some API calls marked as experimental, which are extremely prone to being changed or removed, alpha, which can be changed or removed but with a little bit more caution, beta which wouldn’t be changed or removed without a deprecation period, and stable which is core and won’t change without a major version change.

I’m totally happy if 100% of the API endpoints are in the experimental phase at the beginning of the public API, but it’s nice to see which APIs are progressing towards stability over time, and which remain totally experimental.

5 Likes
#11

@Silver I would vote for bringing in beta testers early, but with the caveat that you limit the number of people who have access. Perhaps stage it like you did with the app, bringing in a few more devs every week or something like that. I wouldn’t want the Obsidian devs to get overwhelmed with feedback and requests and plugins. You could have a short application form where the prospective dev describes the first plugin they want to create, and then you can select for a variety of plugin types. At this early stage, I might suggest the process be more about hammering out the API and less about creating finished, polished plugins for deployment to the wider community.

Re: @anshbansal and auto-updating, WordPress might be a good model. Users have to manually update all plugins, and plugins have to report what minimum version of the app they are compatible with. WordPress also forces a minimum PHP version, which may not be necessary with JavaScript/TypeScript and compilers.

Disabling all plugins = maintenance mode

Second @ksandvik on building the API in TypeScript. Have you considered what kind of documentation tooling you are going to use?

1 Like
#12

We do everything in TypeScript internally, so it should be pretty easy to release the definition files too. For developers who don’t use TypeScript, they can just skip it.

7 Likes
#13

Typescript, hurrah. I’m not a big fan of the sloppiness with Javascript coding.

As a bonus the plugins are also more robust.

#14

I am very okay with unstable API. I think it is also a better solution in the long term: it is impossible to stabilize and API without people trying to use them in the most absurd possible ways. :grinning:

4 Likes
#15

Throwing my hat in the ring for unstable API. Everyone above has pretty much covered my thoughts, so I don’t have much to add. But the sooner we can do anything, even if it breaks, the sooner we know what’s possible or not. :slight_smile:

#16

Unstable API sounds great!

Unless you guys want to support multiple API versons. For example, v0.1, v0.2, v0.3, etc. Developers can specify which version they’re working with. Then perhaps depricate all old APIs at once. That way, things aren’t constantly breaking, but only breaking in batches every few months.

2 Likes
#17

Personally I think it’s better to break the API and force plugin fixing/changes especially as end users will not freeze their Obsidian version, they just happily update. Keeping old APIs around for backwards compatibility just adds more cycles to maintain those rather than using the engineering resources fixing new APIs and features.

3 Likes
#18

Like the many posters above, I just want to add my support and interest for developing using an unstable API.

1 Like
#19

Just another +1 for no-warranty beta SDK - very much looking forward to exploring.

2 Likes
#20

I am also up for the unstable beta API!

2 Likes
#21

Same here! Would love to hack on stuff!

1 Like
#22

Anything that gets us past the roam cult.

8 Likes
#23

Count me in on the constantly-breaking-beta-API train :slight_smile:

1 Like
#24

+1 on breaking APIs. I think this will accelerate developing a good API. Plus I’m champing at the bit to fix the main feature hole that is still missing for me (music notation).

2 Likes
#25

+1 on breaking APIs. I just want to fool around for a bit and push this to the limit!

1 Like
#26

I’ve been itching to add on some functionality that I need. Unstable api is better than nothing :smiley:

1 Like
#27

Received everyone’s feedback and we’ll go with an unstable API first!

11 Likes
#28

Is this something that is already close to ready? Or is there at least some kind of timeline to expect this? Absolutely no rush, just interested because I’m on leave for a month, so I have some time to hack on this :slight_smile:.

#29

Currently no timeline, sorry! Check back in a month or so and hopefully we have something almost ready for testing.