Serum/Openbook program removed?

[cloakd]

Previously there were decoders available for serum (openbook) in ./programs however these have now been removed.

This breaks backwards compatibility for pretty much any version using solana-go for raydium as this program we being used for the openbook side of the markets.

[cloakd]

Was cleared off under #357

Serum is sunset but OpenBook is not.

[sonicfromnewyoke]

Was cleared off under #357

Serum is sunset but OpenBook is not.

this is not official program. So, i believe, it's better not to track it under SDK. If someon'e project needed a client for openbook or any other 3rd party program they can easily generate client and needed acount decoders with anchor-go or codama-renderer

[cloakd]

Why is this repo so keen to break backwards compatibility? It has been stable for years but the past month its become an nightmare to upgrade to due to incorrect semvar and core needed features being removed....

[sonicfromnewyoke]

Why is this repo so keen to break backwards compatibility? It has been stable for years but the past month its become an nightmare to upgrade to due to incorrect semvar and core needed features being removed....

1. outdated != stable. In the last 3 years, a lot of things have changed, and we have to match them
2. we do our best in keeping backward compatibility and semver convention, breaking changes go in v2 branch only
3. supporting all the possible 3rd party programs (when every day we see a launch of new program) is not resource-wise. This sdk will be aligned with all other sdks (rust/ts) and will support only official programs

[cloakd]

1. of course but can be done in a way it doesnt break all downstream providers
2. There have been multiple breaking changes in the v1.X so far (biggest on being the SolMint change to an incorrect address)
3. Im not saying to support 3rd party programs, but serum/openbook has been in the original set of programs since almost day 1 & the idl has never changed so can be considered a "stable" program

I think any programs with a "stable" IDL should be accepted in as PR's (will need some community standards on build etc) as its one of the biggest blockers when devs start on Solana

[sonicfromnewyoke]

1. of course but can be done in a way it doesnt break all downstream providers

   2. There have been multiple breaking changes in the v1.X so far (biggest on being the SolMint change to an incorrect address)

   3. Im not saying to support 3rd party programs, but serum/openbook has been in the original set of programs since almost day 1 & the idl has never changed so can be considered a "stable" program

I think any programs with a "stable" IDL should be accepted in as PR's (will need some community standards on build etc) as its one of the biggest blockers when devs start on Solana

1. could you share the specific v1.x breaks you hit besides the SolMint one? It would help me audit what slipped past semver. Going forward, the v2 branch is where breaking changes land, and CI now has a semver check.
2. yes, the SOL == WSOL address bug was bad - im sorry that one shipped under v1
3. on "stable IDLs as the bar": I don't think IDL stability alone is enough, because today anyone can regenerate a client from an IDL with codama or anchor-go in a second. Bundling those generated clients into the core SDK adds maintenance surface without saving users much work. I'd rather keep this repo focused on the primitives - the things that can't be code-generated, like the gaps that make building something like litesvm hard today. That's what I'm working on now.

If you (or the community) want to maintain a curated set of stable-IDL program clients in a dedicated repo, I'm happy to link it prominently from the SDK README - that seems like the right division of labor.