Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for initial 1.0 alpha version #162

Draft
wants to merge 2 commits into
base: 1.x
Choose a base branch
from

Conversation

tcharding
Copy link
Member

@tcharding tcharding commented Feb 23, 2025

Draft so that the following PRs can go in.

Prepare for initial 1.0 alpha release. The target 1.x branch will contain an initial patch that deletes everything from this repo. Then we add back in here stuff we want to release.

Close: #154

@Kixunil
Copy link
Collaborator

Kixunil commented Feb 24, 2025

I may have mentioned it already but I don't have much confidence in iterators. I remember when I tried to change something I ran into issues. Can we please only have the error types and two inherent functions? (I could also accept the trait.)

@tcharding tcharding force-pushed the 02-24-release-1.0-alpha.0 branch 7 times, most recently from ed55fbe to aabe779 Compare February 25, 2025 03:19
@tcharding
Copy link
Member Author

Moved some of the iter code to the 0.4 PR and made the rest doc(hidden). I build the docs and made sure there was nothing there except errors and FromHex.

@tcharding
Copy link
Member Author

tcharding commented Feb 25, 2025

@apoelstra shall I make a 1.x branch then set that as the merge target for this PR? Also I've still to write the changelog and then take this off draft.

src/iter.rs Outdated
@@ -194,6 +194,7 @@ where
/// Generally you shouldn't need to refer to this or bother with it and just use
/// [`HexToBytesIter::new`] consuming the returned value and use `HexSliceToBytesIter` if you need
/// to refer to the iterator in your types.
#[doc(hidden)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this hidden and not non-pub/deleted?

@apoelstra
Copy link
Member

@apoelstra shall I make a 1.x branch then set that as the merge target for this PR?

Yep.

@tcharding
Copy link
Member Author

tcharding commented Feb 26, 2025

After sleeping on this the following thought came to me:

If we are using doc(hidden) to hide unstable stuff why not just hide everything in 1.0 we don't want to commit to and not bother with doing 0.4 at all? Then downstream has only one dependency and we can break what we think we might have to - YOLO.

See rust-bitcoin/rust-bitcoin#3935 for the same in units.

@apoelstra
Copy link
Member

@tcharding because if anybody (including us) actually uses the doc(hidden) stuff then we still cant change their API without breaking downstream users' builds.

@tcharding tcharding force-pushed the 02-24-release-1.0-alpha.0 branch 4 times, most recently from 4bbf256 to ef4111f Compare February 26, 2025 23:33
@tcharding tcharding marked this pull request as ready for review February 26, 2025 23:39
@tcharding tcharding changed the title WIP: Prepare for initial 1.0 alpha version Prepare for initial 1.0 alpha version Feb 26, 2025
@tcharding
Copy link
Member Author

tcharding commented Feb 26, 2025

Open question: I have no idea how we will re-introduce stuff back into this from another branch and have reviewable patches?

@tcharding tcharding mentioned this pull request Feb 27, 2025
@tcharding tcharding changed the base branch from master to 1.x February 27, 2025 04:09
@tcharding
Copy link
Member Author

1.x branch created and merge target set.

@Kixunil
Copy link
Collaborator

Kixunil commented Feb 27, 2025

Open question: I have no idea how we will re-introduce stuff back into this from another branch and have reviewable patches?

Any 1.0 -> 0.x should only happen by adding use. Any 0.x -> 1.0 should only happen by code moves. I think it'll be fine.

@apoelstra
Copy link
Member

Any 0.x -> 1.0 should only happen by code moves.

It might look a little weird in git. Normally you don't "move" code between branches like this.

I think it'll be fine.

But yeah, agreed. We're all pretty good at using git here and we'll figure it out.

@Kixunil
Copy link
Collaborator

Kixunil commented Feb 27, 2025

It might look a little weird in git.

Oh, true, one commit deletes it another adds it. We will need to link them somehow at least.

WIP because this should come from `master` but we are waiting on rust-bitcoin#166 to
merge.

`master` is at tip: TOOD

Introduce decoding logic from `master`, this means:

Public API consisting of:

- The crate level decoding functions
- The associated error types

Private code:

- Code in private modules `parse` and `iter` as needed.
In preparation for doing the first 1.0 alpha release set the version
number, add a changelog entry, and update the lock files.
@tcharding tcharding force-pushed the 02-24-release-1.0-alpha.0 branch from ef4111f to ac56fb4 Compare March 3, 2025 22:41
@tcharding
Copy link
Member Author

After talking with @apoelstra today I pushed a few changes

1.x:

  • Has had all the history removed (reset to the initial commit)
  • Has two patches on it. One introduces non-code stuff from master and the next introduces an empty crate and CI.

This branch:

  • Has a wip (waiting for PRs to merge) patch that introduces the code we want to release
  • Has a patch bumping the version number

Please concept ack/nack this. Another solution would be to put the two patches on 1.x at the front of this PR

@apoelstra
Copy link
Member

concept ACK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Stabilize only part of the crate
3 participants