2016-12-13 17:41:17 +00:00
|
|
|
# When cleaning up this file: bump API version in corresponding Makefile.am and rename corresponding debian/lib*.install
|
osmo-release.sh: Always generate entire commit changelog
Before this commit, for library projects (containing LIBVERSION in some
Makefile), the entire commit list was not stored into the changelog, but
only a few lines from TODO-RELEASE files.
This is a bad approach for several reasons. First, because that file was
only aimed at containing API/ABI breaks, and not the full relevant
changeset (like bugfixes, new features, etc.). Second, because it relies
on every developer making API/ABI changes to remember to store the
change in there during commit break time.
Let's instead always store the entire commit list in changelog, and
let's use TODO-RELEASE only as a list of hints for the maintainer to
help him evaluate how LIBVERSION needs to be bumped for each library.
Other tools such as osmo-abi-check.git can be used to help with the
process of decission too.
Let's take the opportunity too to only commit stuff already added to the
staging area, as it proved easier to manage from my personal experinece
making latest releases.
Change-Id: Ibf662173ce2b4ff3966e9ad5f56c65dfb13607ff
2018-05-03 13:01:47 +00:00
|
|
|
# according to https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
|
|
|
|
|
# In short: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info
|
2016-12-13 17:41:17 +00:00
|
|
|
# LIBVERSION=c:r:a
|
|
|
|
|
# If the library source code has changed at all since the last update, then increment revision: c:r + 1:a.
|
|
|
|
|
# If any interfaces have been added, removed, or changed since the last update: c + 1:0:0.
|
|
|
|
|
# If any interfaces have been added since the last public release: c:r:a + 1.
|
|
|
|
|
# If any interfaces have been removed or changed since the last public release: c:r:0.
|
2016-04-21 12:46:30 +00:00
|
|
|
#library what description / commit summary line
|
2021-03-04 20:25:11 +00:00
|
|
|
libosmovty _LAST_OSMOVTY_NODE Raise _LAST_OSMOVTY_NODE by introducing some RESERVED*_NODE
|
2021-04-19 10:24:02 +00:00
|
|
|
libosmogsm gsm0808_old_bss_to_new_bss_info ABI break (struct changes size), gsm0808_old_bss_to_new_bss_info_att_tlvdef symbol added
|
2021-04-25 18:50:13 +00:00
|
|
|
libosmosim osim_card_hdl ABI + API breakage due to new struct members
|
2021-04-27 23:36:23 +00:00
|
|
|
libosmocore osmo_tdef_fsm_inst_state_chg change default_timeout arg from unsigned long to long type (API breakage, not ABI)
|
2021-05-18 12:46:29 +00:00
|
|
|
libosmovty vty_read_config_filep New API
|
2021-06-01 18:11:19 +00:00
|
|
|
libosmosim osim_card_{reset,close} New API
|
2021-05-31 11:10:24 +00:00
|
|
|
libosmocore struct rate_ctr_group, osmo_stat_item_group_desc ABI breakage due to new struct members
|
2021-05-19 15:45:38 +00:00
|
|
|
libosmgsm kdf functions New API
|
stats: send real last value if no new values come
Background:
* Individual values can be added to osmo_stat_item.values at any time.
* Stats are reported at a fixed interval (see vty 'stats interval'),
e.g. every 10 seconds.
* In order to report a new stat value, we use the maximum of all
osmo_stat_item.values added since the last report.
* By default, we do not send new stat values if they did not change
(see vty 'config-stats' -> 'flush-period' default of 0).
Fix the following bug:
* If 'flush-period' is 0, and no new osmo_stat_item.values are coming
in, the last value that gets reported is not necessarily the last
entry in osmo_stat_item.values.
* For attached reporters (statsd), it could then be that the given stat
stays at the wrong value for a long stretch of time (think of several
hours/days/forever).
Explanation of how the test shows that it is fixed:
* stats get reported (value is irrelevant)
* osmo_stat_item gets a new value: 20
* osmo_stat_item gets a new value: 10
* stats get reported (value: 20, the maximum of both new values)
* osmo_stat_item gets no new values
* stats get reported (value: 10, this is new because of the bug fix,
the real last value in osmo_stat_item, different from the 20 sent
earlier, without the fix it would not send anything here and the last
sent value would be 20)
* osmo_stat_item gets no new values
* stats get reported (nothing gets sent, since the real last value was
already sent and 'flush-period' is 0)
Fixes: OS#5215
Change-Id: Ibeefd0e3d1dbe4be454ff05a21df4848b2abfabe
2021-08-19 09:58:09 +00:00
|
|
|
libosmocore osmo_stat_item ABI + API breakage due to new struct members
|
