obgm / libcoap

A CoAP (RFC 7252) implementation in C

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

4.3.3 tag archive checksum has changed

samford opened this issue · comments

Hi, I'm a Homebrew maintainer and I noticed that the sha256 checksum for the 4.3.3 tag archive (https://github.com/obgm/libcoap/archive/refs/tags/v4.3.3.tar.gz) changed between when we updated our formula and now. It was 3df6e1a51e42ef8fd45f16276505a47ed32aef150d348d60f251a0b470dda379 when we updated (2023-09-12) but is now 790a657daa98f942560859b432de7672a0ac5ff171d861ba7fc997d793e1a2c8.

Before we update the checksum on our end, we like understand the upstream situation (to make sure we're not pulling in unwanted changes, etc.). Was v4.3.3 retagged and, if so, what changed?


Additionally, is there any specific process that you follow for releasing a new version that we should be aware of? At the moment, we update our formula when there's a new stable tag in the repository (e.g., v4.3.3).

Should we be checking the tag version link on the homepage instead? That is to say, is the version on the website updated at the same time a new version is tagged or is it updated later when the version is considered to be released?

Apologies to the confusion created here - something we were internally looking at how best to move forward clean things up before you raised this issue.

The sequence of events were that we discovered that the .so ABI for release 4.3.2 was incorrect (as libtool (correctly) 'mangles' the provided SO version), so 4.3.3 was created, just fixing the ABI version and the original v4.3.3 tag was created. It was then realized that the code version had not been updated to 4.3.3, so this was corrected and the v4.3.3 tag updated to include this change.

So, the only change between the old and current v4.3.3 tag is the replacement of 4.3.2 with 4.3.3 in the appropriate places and no other logic change. Both the main and release-4.3.3 branches are at the current v4.3.3 tag.

The website home page gets updated as appropriate after a new tag is created, but there could be a few days lag here.

In general, the new stable tag in the repository is the way to go. We wont be making this mistake again.

Thanks for the detailed clarification! We'll move forward with updating the checksum on our end and continue checking stable tags for new versions.