Create a release

[shazow]

I'm trying to add a homebrew install recipe for secp256k1 (Homebrew/legacy-homebrew#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]

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

This will hopefully change soon.

[shazow]

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

[sipa]

I'll leave this issue open until then.

[lukateras]

Or you could just cut a v0.x tag.

[dcousens]

@shazow you can't use a commit hash?

[shazow]

@dcousens Correct. It's a homebrew requirement.

[gmaxwell]

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.

[afk11]

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]

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?

[afk11]

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]

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

[skywinder]

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?

[real-or-random]

We really should have releases.

Is there anything that prevent us from doing this?

[afk11]

@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]

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]

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.

[A6GibKm]

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]

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

[niooss-ledger]

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.

[rickmark]

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

[real-or-random]

solved by #1055.

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