New release?

[minad]

@sjaeckel Would it make sense to cut a new release at some point and remove deprecated stuff afterwards? Are there open issues right now which stand in the way of a new release?

Or do you want to have all the open PRs resolved until then?

[sjaeckel]

Would it make sense to cut a new release at some point and remove deprecated stuff afterwards?

definitely!

Are there open issues right now which stand in the way of a new release?

not that I know of

Or do you want to have all the open PRs resolved until then?

not all, but those that make sense to have them rolled out to a wider audience

originally I wanted to make a v1.1.1 but forgot about it and now we can also see if we can immediately go with 1.2.0

@lvc can you please check why ltm isn't updated on https://abi-laboratory.pro/?view=timeline&l=libtommath? I'd like to see the differences to current develop

[lvc]

@lvc can you please check why ltm isn't updated on https://abi-laboratory.pro/?view=timeline&l=libtommath? I'd like to see the differences to current develop

The report has been updated.

[minad]

@sjaeckel Don't know what your plans are now but I think I would rather continue to deprecate a few more things in the public API (some of #243, depending on what you like, starting with #245).

If #244 gets merged the public API will get quite a bit more annoying for the lib user, so it shouldn't matter if we add a few more warnings on top.

We will make sure that everything stays API/ABI backwards compatible obviously until the deprecations are removed.

[minad]

@lvc Doesn't this report update automatically via polling every few days?

[lvc]

@lvc Doesn't this report update automatically via polling every few days?

Working on restoring the service since Apr 4 due to the compute server storage failure. Need 1 more month to complete. So temporarily I update reports manually by request.

[lvc]

Report has been updated.

[lvc]

Feel free to ping me to update reports during this period.

[minad]

@sjaeckel Maybe we could also make a plan here. For now I don't intend to change many more things (deprecation/incompatibilities) in the public api.

[minad]

@lvc Could we please get another compatibility report?

[minad]

Btw, is there something like a global symbol database, e.g. over all debian packages? This would help guiding deprecation decisions and it would help to estimate the impact of certain changes. This is relevant for example for #294. Ping @dod38fr

[dod38fr]

I've never heard of such a DB. OTOH you can search the soon-to-be-deprecated function calls in the source of all packages on https://sources.debian.org/

HTH

[minad]

@dod38fr Thanks! This is better than nothing!

The downside of this search in contrast to symbols from shared objects is that there are many hits due to the library being vendored. In the debian binary packages this duplication would be gone. But who am I to complain - happy Debian user for years :)

[sjaeckel]

ping @lvc :-)

[sjaeckel]

thx @lvc

BTW. I've the impression that the latest build isn't updating correctly, there should be more than 7 new symbols!

[minad]

That's weird. All these set_i32 symbols etc are missing, which were added in 20ae9fb