We should stop adding stuff to the library

[tcharding]

We are primarily trying to get to v1.0, we have limited resources and time, as all projects do.

I propose that we stop adding arbitrary functionality to the public API. Doing so increases maintainer burden and slows down the 1.0 release. I propose that we only add stuff that is "essential" (by some definition) for the 1.0 release or essential for some user (i.e., if it can be done without change to rust-bitcoin then don't change rust-bitcoin).

This is counter to the current policy of adding anything that anyone claims is useful for them. Point in note #2230.

[Kixunil]

#2230 was a simple function that was easy to review. I did it in time slots where any other work wouldn't be feasible anyway.

I'm somewhat inclined to agree not to expand API too much. Though some cases affect the existing API like in #2347 where the latter changes improved previous commits (you don't see those because I rewrote the history locally before first push). Yeah, I got carried away a bit, I didn't expect borrowing errors. :) And speaking of #2347, I'm totally fine with implementing just the first commit for now.

But speaking of optimizations, I also suggest pausing unneeded refactors such as reorderings, rewordings, ... Also we should first focus on the leaf crates. Let's get hashes,units and primitives ready ASAP. That will bring the most value to people since they won't have to update the world when things change.

[tcharding]

But speaking of optimizations, I also suggest pausing unneeded refactors such as reorderings, rewordings, ... Also we should first focus on the leaf crates. Let's get hashes,units and primitives ready ASAP. That will bring the most value to people since they won't have to update the world when things change.

I have been 100% focused on the leaf crates (incl. io). Error handling I'm chipping away at in the afternoons when I'm brain fried. "unneeded refactors such as reorderings, rewordings" I don't believe many of these are going through and if they are they shouldn't be causing you any problem now we have the refactor carve-outs, you can ignore them. It may cause you rebase work, is that what you mean? If they don't get done when I'm poking around the code I don't see when they will get done, when we drop the 1.0 release I would like the codebase to be in a state where I'm proud to say I spent 3 (probably more by then) years working on it. I expect it to be clean AF.

[Kixunil]

It may cause you rebase work, is that what you mean?

Yes, rebases are generally a huge PITA. Thankfully the recent discovery of rerere helped - the last rebase wen completely automatically because of it even though GH complained.

when we drop the 1.0 release

You can write down notes what you wanted to clean and do it right before 1.0 or perhaps we could try to coordinate better (this is somewhat SVN-style but I would try it anyway).

[dpc]

My (maybe a bit off-topic) thought while casually lurking at some issues/PRs/discussions: Aren't you (rust-bitcoin developers) stressing too much about that 1.0 number? IMO the right way to arrive at 1.0 is noticing that the current state of affairs is good enough and release 1.0 then aka "it's ready when it's ready".

The more stuff is polished and less downstream churn is needed the better, and it seems things are progressing toward that direction just fine. As a downstream consumer I'm primarily happy about that, and less about some arbitrary numbers. So unless you feel like things are spinning in circles with refactors, I think it's OK to enjoy the journey without stressing about the destination.

I would like the codebase to be in a state where I'm proud to say I spent 3 (probably more by then) years working on it. I expect it to be clean AF.

You can start being proud already, because "clean AF" moment never arrives and the moment you release 1.0 you start regretting that you can't cleanly fix something anymore - new major release definitely does not seem worth it. Then people start reporting more issues, more ideas for improvement, the list of regrets grows, you start getting slightly depressed, less energetic, you start refactoring your dotfiles to compensate, then you need a drink to make a commit, then two, and before you know your family doesn't want to know you anymore and that 1.0 ruined your life. True story, happened to a friend ;). That's why no one in Rust community releases 1.0 anymore, and there was an RFC hardcoding major version to 0 for new crates as a safety measure (classic Rust community move).

[apoelstra]

@dpc no, 90% of the work that we do right now is working to an API that we can commit to for the long term. By definition once we're done then all that work goes away. (Until we start thinking about 2.0 maybe :))

We definitely don't want to do 1.0 "whenever it feels ready". Then it will never get finished and instead we'll all just burn out and leave the lib hanging at some random 0.x number.

That's why no one in Rust community releases 1.0 anymore, and there was an RFC hardcoding major version to 0 for new crates as a safety measure (classic Rust community move).

Bluntly, the "Rust community" is a dumpster fire and the less we have to interact with projects outside this bubble, the less bullshit we have to deal with. And this is true even if you limit yourself to the technical aspects related to cargo/crates.io, without even touching the social issues.

[Kixunil]

even if you limit yourself to the technical aspects related to cargo/crates.io

Hehe, then everything else is dumpster fire squared. :D Cargo/crates is the least bad dependency management for software development (not programs/system libraries/...) I came across so far.

[apoelstra]

This is fair -- I really can't stand cargo but it's miles ahead of npm, which in turn is miles ahead of pip, for example :).

[Kixunil]

Interesting, I personally had much fewer problems with PIP than NPM but it might have something to do with the libraries being mature so most projects depend on those (and many are packaged in apt too).

[dpc]

I don't think we're stressing too much.

Good, good. Just checking. :)

So at least for these things polishing them and releasing 1.0 of their respective separate crates can greatly improve things.

The improvement is more in the act of polishing APIs, so there's no need to break them anymore, not the 1.0 is just a consequence of it. I guess that's my point.

Focusing on polishing the APIs is great. But it takes time and very little can be done to actually speed it up artificially.

Until we start thinking about 2.0 maybe :)

Exactly. :D

Bluntly, the "Rust community" is a dumpster fire (...)

The RFC hardcoding major versions to 0 thing was a joke! :D

BTW. Problems with package managers come down to "hell is other people". The fewer dependencies, the less you have to worry about other people.

[Kixunil]

One more idea to improve development speed: do minimal changes in commits. Not just small commits but also try to avoid things like renaming Read to io::Read in the whole crate (yeah, I'm the one who ACKed, won't ACK such things in the future I guess). Or if you need to move a file do it in a single commit (possibly with required changes to patch up compilation). rerere can then work with it properly as I found out recently.

[Kixunil]

Try having an outstanding super-large pull request for a few months.

[tcharding]

Oh one that hasn't been touched for a few weeks, that would hurt. I see why that would make you want to not see any "trivial" changes. You could consider flagging those PRs and I could rebase them weekly for you. It would force me to even more deeply understand the PR too. If I introduce bugs though it might make it even more annoying for you.

[tcharding]

Especially if its work that is not super interesting (or you lost interest in it) but we really want to see get merged.

[Kixunil]

split hash trait PR please? :)

[tcharding]

Hell yeah, I can do that one - I'm dying to see some forward progress on hashes and have no clue where to push. Will take a look.

[yancyribbens]

I think there needs to be a focused window of maybe a few weeks or something where no new changes are added to create a release. However an indefinite freeze of adding new useful functionality seems stifling for the project. In this case, I'm not sure how long the proposed no merge window is and for how long I should sit on potentially useful changes.

[apoelstra]

However an indefinite freeze of adding new useful functionality seems stifling for the project.

The idea is that we zero in on 1.0 and then everything else is purely additive. And if there were non-trivial pieces of new functionality, those would need to go into new 0.x crates (at least initially, until they had stable APIs).

But I agree that these seems premature. Let's figure out PSBT at least first.