release v3.10.0

[cspiel1]

Create/Prepare PRs for new Release (re/baresip)

• Update CHANGELOG.md
  • Click Draft a new release on Release page
  • Fill a new release tag version and title (like v2.4.0)
  • Press Generate release notes
  • Save as draft (don't publish yet)
  • Copy release notes to CHANGELOG.md
• Update debian/changelog
• Check/Inc version numbers
  • CMakeLists.txt
  • include/baresip.h
  • mk/Doxyfile
• Check ABI compatibility
  • CMakeLists.txt (Bump PROJECT_SOVERSION)
• Comment out PRE Release identifier -dev
  • CMakeLists.txt
• All tests green? [re, baresip]

Release

• Merge PRs in this order
  • libre
  • baresip
• Publish draft Releases (follow the same order)
  • Maybe Generate Release notes is needed to update (delete last notes first)

After Release

• Bump main branch versions with PRE Release identifier -dev
  • CMakeLists.txt
  • include/baresip.h (baresip only)

Release schedule

• v3.6.0 18. Oct (@alfredh)
• v3.7.0 22. Nov (@cspiel1)
• v3.8.0 27. Dec (@sreimers)
• v3.9.0 31. Jan (@alfredh)
• v3.10.0 6. Mar (@cspiel1)
• v3.11.0 10. Apr (@sreimers)

[cspiel1]

@sreimers in

git diff v3.9.0 -- include

there are no changed/removed functions. Only added functions. Is it okay to let SOVERSION unchanged?

[sreimers]

there are no changed/removed functions. Only added functions. Is it okay to let SOVERSION unchanged?

Looks like there is a indirect change, so bumping should be required I think:

Run abidiff old/build/libre.so current/build/libre.so
Functions changes summary: 0 Removed, 1 Changed (125 filtered out), 6 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

6 Added functions:

  [A] 'function int conf_get_i32(const conf*, const char*, int32_t*)'    {conf_get_i32}
  [A] 'function int fmt_timestamp_us(re_printf*, void*)'    {fmt_timestamp_us}
  [A] 'function int re_text2pcap(re_printf*, re_text2pcap*)'    {re_text2pcap}
  [A] 'function void re_text2pcap_trace(const char*, const char*, bool, const mbuf*)'    {re_text2pcap_trace}
  [A] 'function void tls_enable_verify_client(tls*, bool)'    {tls_enable_verify_client}
  [A] 'function int tls_verify_client(tls_conn*)'    {tls_verify_client}

1 function with some indirect sub-type change:

  [C] 'function int bfcp_listen(bfcp_conn**, bfcp_transp, sa*, tls*, bfcp_conn_h*, bfcp_estab_h*, bfcp_recv_h*, bfcp_close_h*, void*)' at conn.c:169:1 has some indirect sub-type changes:
    parameter [4](https://github.com/baresip/re/actions/runs/8171227422/job/22338999620#step:8:5) of type 'tls*' has sub-type changes:
      in pointed to type 'struct tls' at tls.c:43:1:
        type size hasn't changed
        1 data member insertion:
          'bool verify_client', at offset 200 (in bits) at tls.c:4[8](https://github.com/baresip/re/actions/runs/8171227422/job/22338999620#step:8:9):1

[cspiel1]

Interesting tool. Thanks!