Note to self: PR filter is:pr is:closed merged:>=2024-07-30 label:C-units and included everything from #3915

Issue #3868 has been addressed on units in #3938.

This now demos the idea I posted about here: on the hex alpha release PR

We can use doc(hidden) to hide the amount module and hence only include stuff that is stable.

We cannot for the same reasons we have #4062 open.

• Removed doc(hidden) thing
• Set draft until amount is ready
• Put some time into the changelog

FTR 1.x now starts with a 'delete everything' patch.

If the process in hex is good we can do the same here. rust-bitcoin/hex-conservative#162 (comment)

In my mind alpha and rc are interchangeable terms, am I wrong?

In my mind:

• alpha = half-broken unfinished, unstable, bunch of bugs - basically what units is now considering the MAX_MONEY issue
• beta = almost done, still has bugs - what units will be after fixing MAX_MONEY, I think
• rc = release candidate - we would like to just release this but this is the final call for testing, just in case all is good

Also I'm not convinced that we should do it the same as in hex-conservative since the situation is different. We shouldn't really need 1.x branch here at all, because we will no longer be developing on 0.x. Just make the changes to master. The only case I think we would need a branch is if we bump MSRV with a minor version change and then some nasty problem appears that is worth backporting to older MSRV. But that's just backports.

Re the rc/alpha name, I don't personally care. What ever you and @apoelstra want is fine for me.

Re the 1.0 branch: We cannot release from master while we don't have amount in the release. I'm not the release guy so its more Andrew's decision than mine. I'm just pointing out the technical limitations.

Unless someone finds a reference saying I'm wrong about categorization, I prefer the name alpha.

So IIUC if we tried to release amount-less crate bitcoin would break. But since what we're releasing is alpha anyway, how about keeping the amount behind internal-bitcoin-feature-will-be-removed-in-1-0 flag for now that we will remove in 1.0? Just put that in Cargo.toml, slap #[cfg] on the amount module (and reexports) and depend on it from our crates. When we get the amount into state where releasing is not embarrassing we will just remove the feature.

We shouldn't really need 1.x branch here at all, because we will no longer be developing on 0.x.

If we aren't releasing any 1.0s until we are 100% complete then what is the point of all the extension traits we've been adding?

More generally, it's extremely frustrating that every time we find a way that we can get some 1.0 crates out the door so that people can use stable versions of essential parts of rust-bitcoin, you seem to want to add delays of the form "well first we would need to do a bunch of unrelated things". We don't. Under a very wide set of circumstances, we can ship a 1.0 crate containing large subsets of our API.

This lets downstream users start using those, smoothing their transition difficulty (especially when we expose 1.0 types as reexports from unstable versions, so they don't even need to juggle multiple versions themselves) and reducing the API surface area that we need to keep in our heads as we iterate on the rest.

So IIUC if we tried to release amount-less crate bitcoin would break.

Why? If bitcoin really can't use it then it doesn't have to, but also I can't see why bitcoin wouldn't be able to use it.

But since what we're releasing is alpha anyway, how about keeping the amount behind internal-bitcoin-feature-will-be-removed-in-1-0 flag for now that we will remove in 1.0?

Because then we have a bunch of janky "--all-features doesn't work" type conditions on our crates that we have to keep track of.

Regarding the naming, let's please just do whatever @Kixunil wants because it doesn't matter and arguing is exhausting. So alpha it is I guess.

If we aren't releasing any 1.0s until we are 100% complete then what is the point of all the extension traits we've been adding?

Shit, I wrote it in a confusing way. I meant we won't be developing 0.x primitives and units. So they don't need a dedicated branch, just master works. Having both bitcoin which is 0.x and the others in the same branch/repo is completely fine and preserves the git history - please let's try preserving it.

"well first we would need to do a bunch of unrelated things"

I have no idea what exactly you have in mind. It seems like there's something else bothering you than the misunderstanding above but I can't figure out what it is.

Why? If bitcoin really can't use it then it doesn't have to, but also I can't see why bitcoin wouldn't be able to use it.

Because it depends on it right now, and if we want to release an amount-less alpha version before fixing the amount thing we should temporarily hide it from users. I could also accept #[doc(hidden)] with a comment if that's your thing, I just found a feature to be more robust.

Because then we have a bunch of janky "--all-features doesn't work" type conditions on our crates that we have to keep track of.

It's not an issue, the code must still work correctly, it's just unfinished and rather than deluding the users into thinking this is how Amount will look like when we're 100% sure it won't we can just hide it temporarily.

Shit, I wrote it in a confusing way. I meant we won't be developing 0.x primitives and units.

We will be, because in particular Amount will be in units 0.x while units 1.0 is already out.

I have no idea what exactly you have in mind. It seems like there's something else bothering you than the misunderstanding above but I can't figure out what it is.

Yes, that it sounds like you want to finish Amount before releasing any final version of units, meaning that the entire units crate remains in limbo until Amount is done. When just a few comments above you said we were good to move forward on 1.0 without first completing Amount. "OK, I consider that a sufficient reason to do this and it clears things up (why so soon and why bother with alpha and not just go rc)."

IOW I can't do any downstream work with units 1.0 until we do Amount, which needs to be done from inside a units 0.x crate that contains a ton of other stable-but-for-some-reason-unreleasable stuff that we need to be careful not to touch.

Because it depends on it right now, and if we want to release an amount-less alpha version before fixing the amount thing we should temporarily hide it from users.

Why? If users need Amount then they can use the 1.0 types reexported from units 0.x (which would then be a re-export of 1.0, plus the Amount type).

I may be a massive drama queen but anyways ...

1. I'm tired. I'm worn out. I'm questioning even being involved in open source development - I just want to fucking ship something.
2. I have absolutely zero confidence that @Kixunil will ever sign off on a 1.0 crate - there will always be one more thing.

Solution:

1. We ship units 1.0-alpha.0 right now, as it is, from master.
2. (No one is going to test this anyway except us and we know not to rely on amount)
3. We get amount 'done'
4. We ship units 1.0-alpha.1
5. Repeat for primitives
6. We release bitcoin with dependencies on the alpha releases
7. We move on to downstream testing
8. Everyone in the eccosystem starts using the alpha releases thanks to me pushing upgrade branches all over the place
9. Eventually enough people say "why not just release 1.0 already" that we can override Kix and do it.

I'm not the boss, that is @apoelstra's burden to carry, and no hard feelings @Kixunil but IMO we should override your opinion and just fucking release already.

@apoelstra please BDFL in #4204, tag and release units 1.0.0-alpha.0. Kix is a big boy, he will handle it.

In my mind:
alpha = half-broken unfinished, unstable, bunch of bugs - basically what units is now considering the MAX_MONEY issue

That was written by @Kixunil above and my request is perfectly in line with this view.

I'd prefer we attempt to strip amount for the alpha because we expect it may change. This "alpha" is a release candidate, we're just calling it an alpha to reduce the amount of bitching. (Although, if that doesn't work we might as well just switch to calling it a rc.)

If we pull amount into the new release, that guarantees at least one more "alpha" before we can cut an actual 1.0, and every one we cut requires downstream users to edit their Cargo.toml at least, and if we actually break stuff they may even have to edit their code. So it doesn't accomplish anything as far as going to stability.

I want a situation where I move elements, simplicity and miniscript over to units 1.0-alpha/rc/whatever, and then when everything works fine, we just re-release as 1.0 and update those crates' manifests. (And if it doesn't work fine, ok, we need to cut another one.)

All this is just for testing, right? No one can actually release anything with units because its too useless on its own. So we have to patch manifests to test. The only benefit I see in the release is that we are currently parallelised and unable to release anything. Its a solution to the social problem because it is socially acceptable to release an alpha with broken stuff in it. Unless we release all the alphas right now (bitcoin, primitives, and units) - if I was BDFL I would do that.

I"m operating under the assumption that we will be the only ones doing downstream testing for now. And if others help the alpha is enough to give us some grace.

No one can actually release anything with units because its too useless on its own.

We can immediately use it for locktimes and weights in rust-elements and rust-miniscript. These are the most important units -- Miniscript barely works with amounts at all, and Elements has its own confidential amount type. We can also use it in rust-simplicity, which is currently Elements-only.

Sorry man, this whole thing is doing my head in. I"m off doing downstream testing with a bunch of branches I created on my own tree. I'll come back when I've cleared my head.

For fun here is the miniscript one I just got done: https://github.com/tcharding/rust-miniscript/tree/bitcoin-alpha

(FWIW in hex-conservative and rust-bitcoin repos branches are called alpha. In downstream repos branches are called bitcoin-alpha)

We will be, because in particular Amount will be in units 0.x while units 1.0 is already out.

Why wouldn't we develop Amount on master and release it as 1.0? There's not really that much work left. The MAX cleanup is big and annoying but after that and a careful API review I don't see any big reason to hold off.

Yes, that it sounds like you want to finish Amount before releasing any final version of units,

Yes but isn't this PR trying to do the same? At least that was my understanding.

the 1.0 types reexported from units 0.x

That sounds like too much work for how soon we can release 1.0. I'm pretty sure we'll be able to release 1.0 within a ~month of fixing the MAX thing. Can't it wait?

I have absolutely zero confidence that @Kixunil will ever sign off on a 1.0 crate - there will always be one more thing.

It's funny, because I thought units is pretty much finished except errors (which are now hidden, so all is good) until I learned about that MAX thing. Anyway, if it helps how about this: we clean up the MAX stuff, I will then take some time to review the entire units with the deadline being one week from the moment of merging the cleanup. During that time I will open all issues I find and clearly mark them (or mark the existing ones correctly). Then we fix those issues only and you have my word that I will be fine with the release once all of them are done. And of course, I will also PR what I can.

No one is going to test this anyway except us and we know not to rely on amount

You might be right and I'm fine with that but maybe slap #[doc(hidden)] on the amount module and the reexport during the release just in case? It's just a few trivial lines.

Eventually enough people say "why not just release 1.0 already" that we can override Kix and do it.

Good way to lose contributors

I'd prefer we attempt to strip amount for the alpha because we expect it may change.

That's literally what I intended by the feature. The idea is that adding a few #[cfg]s is way less diff lines than deleting and later adding it.

No one can actually release anything with units because its too useless on its own.

Exactly. The only crate I know of that can use units is ln-types but that one depends only on Amount. :)

That sounds like too much work for how soon we can release 1.0. I'm pretty sure we'll be able to release 1.0 within a ~month of fixing the MAX thing. Can't it wait?

I do not believe you that it's "not a lot of work" to do MAX and that it's "not a lot of time" after that that we can release. We've had multiple years of this sort of "oh just one more thing" thinking and we have released zero things. We've recently realized that we can start shipping things piecemeal, which I was excited about because it lets us start actually using this library instead of endlessly hacking on it, it lets us make tangible progress, and it will reduce the size of the remaining "things that need to get done". Also, by having released APIs that must not change in breaking ways, we will constrain the design space for remaining stuff and hopefully reduce the amount of endless attempts to emulate perfect APIs by contorting ourselves into broken corners of the language.

Exactly. The only crate I know of that can use units is ln-types but that one depends only on Amount. :)

I have repeatedly and explicitly listed multiple crates that I maintain that can use units even without Amount.

Good way to lose contributors

I could say the same about your unwillingness to compromise on API purity for the sake of delivering, and by your continual pushback on our attempts to get things out the door, even when we bend over backward to do so in a way that won't step on your fingers.

FWIW I think the things Kix has been pointing out are valuable. And if that means it takes a bit longer now, rather then needing to retroactively fix things after bugs are found, then it's for the better. The state is of master with respect to Amount is already in bad shape imo because not enough good review and for thought was done, and that's because there wasn't another maintainer to review.

Tobin has been doing a heroic job. His output and constancy is remarkable. Although I think it's unfair to push to override the consensus of a two ack merge just to hurry up. It's not just the Amounts module i've seen Kix find bugs recently that are better to fix now than later. So, Anderw makes the call on if it's better to have just a one Ack policy, although I feel like it's poor conduct to keep pushing him to do so.

Isn't it just the two open PRs and then carefully checking that nothing broke in units?

Anyway, if you think it's that hard, maybe we should just move the Amount back to bitcoin until it's ready and then move it to units again. I'd really want to preserve the history and not have to deal with multiple release branches in usual cases.

your continual pushback on our attempts to get things out the door

For the past months this pushback was much, much lower than my standard. I'm now letting things in that I would've blocked before. But note that part of the pushbak is in fact unblocking us - whenever I want the PRs to be cleaner it unlocks my ability to find a time slot when I'm capable of reviewing it. My capacity to review super-complicated PRs is limited and I sometimes need to wait multiple days before I can.

Anyway, if you think it's that hard, maybe we should just move the Amount back to bitcoin until it's ready and then move it to units again. I'd really want to preserve the history and not have to deal with multiple release branches in usual cases.

Ok, we can do this instead of making a 1.x branch (yet).