fix: sdk release documentation is not correct since agent-js-monorepo split

[gobengo]

Issue: #1035

Contains:

• rm src/{agent,bootstrap} - I believe I had removed this in the original split PR, but somehow they came back (probably do to git auto diff resolution)
• fix issue with nix/agent-js/agent-js{,-monorepo}.nix where we wouldn't properly copy hidden files like /.npmignore to the package output. Downstream, this would cause the release step that uses npm publish --dry-run to fail.
• update docs/processes/release.adoc

[p-shahi]

A part of me thinks, we'd want to do this as a part of the JS agent release process.

[gobengo]

This is the JS agent release process

[p-shahi]

What I'm saying is I'm not so sure we want to couple the release process of the SDK and the release process of the JS and Rust Agents. This is really an artifact of those different components being part of the same repository. Decoupling the components gives us a chance to develop each repos own release process, which will be more important once they are open sourced. For now this is fine and a non blocker but I don't imagine we want to cd agent-js && npm version $NEW_DFX_VERSION for the lifecycle of the sdk

[gobengo]

@p-shahi You're right, and @hansl and I talked yesterday about

• agent-js-monorepo CI will publish to npm, e.g. for @dfinity/agent and eventually other packages
• that will unblock sdk pulling from the npm registry instead of git
• that will unblock us from needing to release sdk-then-agent, and we will then be able to release tagged version of agent to npm, and have sdk depend on new versions as it sees fit.

So yeah, I think we're saying the same thing. This PR just makes the release docs work at all. But soon I will change them again to be more better.

[gobengo]

dfinity/icp-js-core#32

[lsgunnlsgunn]

a few minor suggestions, but for a real review, I would need to test the instructions by driving a release.

[lsgunnlsgunn]

I think the instructions must include how you can build the dfx binary..Being about to do this reliably has been an issue and ideally the release process instructions provide enough information for anyone--including me or Alexa or any other new addition to the team to release without needed any additional "tribal knowledge" or secret handshakes.

To do a complete and honest review of the changes, I would need to actually walk through them from soup to nuts and see if I could complete the task at hand.

[gobengo]

#1036 (comment)

To do a complete and honest review of the changes, I would need to actually walk through them from soup to nuts and see if I could complete the task at hand.

That makes sense. I was doing that as I authored them, but the more eyes the better. On the other hand, we'll be following the docs w/ every Tuesday release, so we could just use that as a testing ground. I'm happy to be validator next Tuesday to note and fix any issues we encounter.

But until this is merged, the docs will definitely be very wrong and hard to follow for next Tuesday :)

[lsgunnlsgunn]

How can step at line 76 happen before this step? Just as text that seems confusing to me, but as I said I would have to do a real run through to see if it makes sense in context.

[gobengo]

Great question.

Line 76 is saving a reference to the 'production release' of the sdk that I assume you already have installed on your system. That's why I call the variable $dfx_system. But later, we're going to build the binary for a 'release candidate' ('rc') for dfx, so I call that variable $dfx_rc (later).

$dfx_system is really only needed so you can compare the outputs of $dfx_system --version and $dfx_rc --version to make sure they are different in the right way in a later step. This step was already in the release, but was ambiguous to me, because it basically just said 'do $dfx_rc --version and validate the output', but not describe the expected output.

[p-shahi]

LGTM, haven't driven the document yet.