chore(release): add prep-release script

[nathanielc]

The Flux release process will now require a preparation step.
This still will make and commit any changes to the source code, i.e.
updating docs to mark the correct version a function was introduced.

The process will be:

1. Run ./prep-release.sh in Flux repo
2. Merge created PR
3. Run IDPE release script (which calls the Flux release script)

The Flux release script checks that the prep step was completed so it
can't be easily forgotten.

Done checklist

• docs/SPEC.md updated
• Test cases written

[nathanielc]

I'd like to add a step to automatically bump the version in the Cargo file too. But the cargo-bump utility we used doesn't yet support workspace based projects. See https://github.com/wraithan/cargo-bump/blob/master/src/config.rs#L102

We can add that behavior of the release later.

[rockstar]

Yeah, this is one of those things that has always bothered me.

There are a couple of cargo tools that don't with workspaces that I use regularly. It makes me sad.

[nathanielc]

Submitted PR to cargo-bump for workspace support wraithan/cargo-bump#34

[nathanielc]

@sanderson FYI we are looking to add this to our release process.

[rockstar]

Run IDPE release script (which calls the Flux release script)

I wonder if we should also run etc/checkprepared.sh in the idpe script.

I'd also like to see a script that is the opposite of etc/checkprepared.sh so that we can assert that both scripts are only being run in their required states. This might seem like over-engineering, but footguns in the release process are guaranteed to go off more than not.

[rockstar]

Nit: "script's" - that lack of apostrophe is gonna get me.

[rockstar]

Wow, this is quite the bash-ism. I had to read it a couple of times to realize what it did, and then spent a little more time trying to think of how I would implement it, and none of them are as efficient as this is.

[nathanielc]

I wanted to do it this way so that if we get spaces in file names it doesn't break.

[rockstar]

Yeah, this is one of those things that has always bothered me.

There are a couple of cargo tools that don't with workspaces that I use regularly. It makes me sad.

[nathanielc]

I wonder if we should also run etc/checkprepared.sh in the idpe script.

I'd rather IDPE know as little as possible about the Flux release process. So that is why the Flux release script calls the checkprepared.sh script itself.

I'd also like to see a script that is the opposite of etc/checkprepared.sh so that we can assert that both scripts are only being run in their required states. This might seem like over-engineering, but footguns in the release process are guaranteed to go off more than not.

I am not sure I follow. Like a checkunprepared script? What would it do? Assert that introduced: NEXT is present? It not always going to be present even in an unprepared repo.

[rockstar]

I'd rather IDPE know as little as possible about the Flux release process. So that is why the Flux release script calls the checkprepared.sh script itself.

I don't think it would be a horrible thing if the IDPE script knew something about our release process (because it is part of the release process, ultimately), but I take your point that if we can avoid it, we should.

I am not sure I follow. Like a checkunprepared script? What would it do? Assert that introduced: NEXT is present? It not always going to be present even in an unprepared repo.

I cannot, for the life of me, remember what I was trying to say here. I think the thing I'm concerned about is that the state of "unprepared" becomes more complex, and maybe the check is about checking versions and tags, etc. I'm not sure that's necessary, at this point. If it gets more complicated, we should certainly think about it, but for now, I retract my statement. :)