Create a release

shazow commented at 1:17 pm on August 7, 2015: none

I’m trying to add a homebrew install recipe for secp256k1 (https://github.com/Homebrew/homebrew/pull/42605) but they require a specific tagged version to include in the mainline tap. Any chance we can tag some commit(s) with some version scheme?

sipa commented at 1:24 pm on August 7, 2015: contributor

We’re currently still considering this code experimental, and don’t have releases or API compatibility yet.

This will hopefully change soon.

shazow commented at 1:28 pm on August 7, 2015: none

Fair enough. Please ping the above issue when you’re ready and we can update the recipe. :)

sipa commented at 1:31 pm on August 7, 2015: contributor

I’ll leave this issue open until then.

shazow cross-referenced this on Aug 7, 2015 from issue secp256k1 by shazow

yanalunaterra commented at 2:47 pm on August 20, 2015: none

Or you could just cut a v0.x tag.

dcousens commented at 10:23 pm on August 20, 2015: contributor

@shazow you can’t use a commit hash?

shazow commented at 10:38 pm on August 20, 2015: none

@dcousens Correct. It’s a homebrew requirement.

gmaxwell commented at 11:24 pm on August 20, 2015: contributor

It’s a good requirement. You should not be shipping split out libsecp256k1. The software is not released, the API is highly unstable, etc. We will release when it’s ready for that.

sipa cross-referenced this on Aug 28, 2015 from issue release state of library vs bitcoin-core by nessence

afk11 cross-referenced this on Nov 19, 2016 from issue Version? by alexreg

sipa cross-referenced this on Nov 28, 2016 from issue Has anyone made an ubuntu package of this lib? by czepluch

afk11 commented at 11:42 am on July 5, 2017: contributor

I noticed this library is being built and shipped in debian/stretch. I’ve asked in #secp256k1 and #bitcoin-core-dev but no-one seems to be claiming it. Emailed the Debian Bitcoin Team to see what the story is.. https://packages.debian.org/stretch/libsecp256k1-0

sugarjig commented at 9:02 pm on August 8, 2017: none

I tried to create a homebrew formula for libbitcoin-explorer, and it has a transitive dependency on this library. I imagine that this issue is blocking lots of other projects from creating homebrew formulae. It’s been exactly 2 years since this issue was opened. Are we any closer to a tagged release?

sugarjig cross-referenced this on Aug 8, 2017 from issue Cannot create Homebrew formula: no tagged release for secp256k1 by sugarjig

afk11 commented at 10:07 am on August 9, 2017: contributor

My update to the above is that whoever packages groestlecoin & bitcoin into debian (contact details are on the link above) is maintaining the package somewhat, but I don’t trust the build. @sugarjig For now can you specify a git commit when pulling in dependencies?

sugarjig commented at 4:05 pm on August 9, 2017: none

@afk11 Unfortunately, no. The official Homebrew taps require a formula be based on a tagged release.

sugarjig referenced this in commit c362d86b64 on Aug 14, 2017

BrewTestBot referenced this in commit ae22d3e61d on Aug 14, 2017

sugarjig referenced this in commit e0a67f4bd4 on Aug 15, 2017

BrewTestBot referenced this in commit cc32c86eaf on Aug 15, 2017

sugarjig cross-referenced this on Aug 20, 2017 from issue libbitcoin 3.3.0 (new formula) by sugarjig

apoelstra cross-referenced this on Dec 5, 2017 from issue Add versioning by skywinder

skywinder commented at 8:40 pm on December 5, 2017: none

We’re currently still considering this code experimental, and don’t have releases or API compatibility yet. This will hopefully change soon.

For the experimental code is considering as release number = 0. i.e. 0.0.1 etc. And minor versions and patch version can change according to normal versioning rules. What about this option?

DBLouis cross-referenced this on Mar 23, 2019 from issue New package: libsecp256k1-20190311+ee99f12. by DBLouis

afk11 cross-referenced this on Sep 13, 2019 from issue Bindings for PHP by afk11

real-or-random commented at 1:01 pm on January 6, 2020: contributor

We really should have releases.

Is there anything that prevent us from doing this?

afk11 commented at 7:44 pm on January 6, 2020: contributor

@real-or-random For context..

gmaxwell (May 2015) #255 (comment) Please be clear in your readme that secp256k1 is unreleased and experimental right now; it shouldn’t generally be used or depended on.

^ this was in a thread where several people discussed already having written language bindings.. the library is very much depended on by others

me (July 2015) #286 (comment)

I noticed this library is being built and shipped in debian/stretch.

^ this out a grostelcoin dev packaging it into debian, but no idea how it’s being built.. if someones going to build it, there may as well be QA

sipa (August 2015) #255 (comment)

Just to let you know that we’re working towards a stable API and tagged release soon.

me (May 2016) #396

That hasn’t happened for a year or so now, so I’m starting to get curious as well.

^ this comment was about bc breaks

gmaxwell (May 2016) #396 (comment)

Actually documenting and publishing on many of the (potentially risky) novel optimization we use is something I consider a requirement before considering a published version here.

why is using this software in bitcoin core OK, but it’s not ok to release the software without publishing the optimizations referred to? @sugarjig (August 2017) #286 (comment)

The official Homebrew taps require a formula be based on a tagged release.

While there have been BC breaks (ecdh api), they’ve become quite infrequent. Making formal releases of these can be scheduled along with linux distribution releases so people have time to work around them.

I really would like to see releases after 4 years of it being an open issue :/ Someone else suggested actually tracking all the blockers for releases in an issue since it grows each time #396 (comment)

gmaxwell commented at 0:33 am on January 7, 2020: contributor

While there have been BC breaks (ecdh api), they’ve become quite infrequent.

They’ve been infrequent because development of the library spent a long time substantively dead.

I really would like to see releases after 4 years of it being an open issue

I wanted co-collaborators to review my minor changes when I was attempting to contribute to the library without me having to beg for weeks at a time and still sometimes get nothing, but we don’t always get what we want.

why is using this software in bitcoin core OK,

I know this has been answered in another PR but because this library was substantially developed for Bitcoin by Bitcoin developers, and the usage in Bitcoin is both extensively tested and also reviewed by the authors of this library. To the extent that the properties of the libsecp256k1 might mismatch the expectations of a user it’s least likely to occur in Bitcoin.

Bitcoin’s usage also is heedful of this. It does not link a system library which might change out from under it and break consensus in some way– it embeds it. It also doesn’t use features of the library like gmp bignum that its harder to be confident of the stability of…

I don’t think there is anything conceptually big that would prevent making a tagged release, but when there isn’t much effort going into it even small things are big. I don’t benefit from there being a tagged release, rather, I expect that it would create some additional cost from demands to keep interfaces more stable… so it isn’t something that I would personally have prioritized.

I’m no longer involved except commenting to avoid unnecessarily leaving a knowledge vacuum, so it isn’t like my position actually matters, but if you’re going to invoke me as some kind of barrier I figure I should comment. :)

afk11 commented at 1:25 pm on January 7, 2020: contributor

but we don’t always get what we want.

To outsiders, there’s a big difference between “no one’s bothered” and “it’s un-actionable because X”, and no-one is going to pick this up if it seems like the latter..

To the extent that the properties of the libsecp256k1 might mismatch the expectations of a user it’s least likely to occur in Bitcoin.

For the most part, applications dependent on libsecp are within the cryptocurrency ecosystem, or simple bindings to secp from other langauges - they expect to match the properties of bitcoin, even if they don’t understand what they are :)

I expect that it would create some additional cost from demands to keep interfaces more stable…

I haven’t seen that request at all within this repository.. BC breaks are a reality for developers, they just shouldn’t be unexpected.

I think all we’re asking for is semver tags on github so software can commit to libsecp256k1 3.x.y or whatever

EDIT: and these on the wishlist

distribution via debian/ubuntu (for a start)
maintain compatibility during lifecycle of that OS release, ie, BC breaks get released in next distro version

if you’re going to invoke me as some kind of barrier I figure I should comment. :)

If it seemed personal I apologize – To me the quotes covered all of the reasons given for why this issue should not be worked on.

joemphilips cross-referenced this on Feb 28, 2020 from issue TODO: Make integration of Secp256k1.Native more secure. by joemphilips

A6GibKm commented at 4:22 pm on July 3, 2020: none

This library is being used to build electrum flatpak with just a random commit. A tag would help as it makes more clear which commits are considered to be working best.

real-or-random commented at 12:45 pm on July 6, 2020: contributor

Just a heads up, we’re working on this. There’s a rough list of things we want to have for a release (certainly up to debate): https://github.com/bitcoin-core/secp256k1/milestone/1

real-or-random cross-referenced this on Sep 18, 2020 from issue Tag a release by luke-jr

niooss-ledger commented at 4:08 pm on December 1, 2020: contributor

Hello, is there any progress regarding tagging a release? If releasing a v1.0.0-rc1 (as mentionned in https://github.com/bitcoin-core/secp256k1/milestone/1) is still expecting to take a few years/decades, would it be possible to add a tag 0.1? This would really help knowing when to update secp256k1 in projects that use it.

SomberNight cross-referenced this on Feb 25, 2021 from issue Any version requirement for secp256k1? (minimum required) by ar-jan

real-or-random cross-referenced this on Mar 24, 2021 from issue Cut a release of 0.X to support a homebrew formula for libsecp256k1 by rickmark

rickmark commented at 9:00 am on March 24, 2021: none

Created issue #909 to introduce the ability to query the version so that clients can decide if the version they bind to is SemVer compatible

prusnak cross-referenced this on Jul 20, 2021 from issue secp256k1: replace local version with nixpkgs by prusnak

real-or-random renamed this:
~~Provide tagged versions~~
Create a release
on Jan 15, 2022

real-or-random cross-referenced this on Jan 15, 2022 from issue Modulo-reduce msg32 inside RFC6979 nonce fn to match spec. Fixes #1063 by paulmillr

real-or-random commented at 11:14 pm on December 12, 2022: contributor

solved by #1055.

I’ve created follow-up issue #1175 and #1176 for open questions.

real-or-random closed this on Dec 12, 2022

Create a release #286