Make a simple release process and release v0.2

[huachaohuang]

This should be the last closed issue before releasing v0.2.

• Add more crate-level documents

[tisonkun]

Previous discussions:

• Project Management #32 (comment)
• Project Management #32 (comment)

[tisonkun]

Apart from the source release, we should also publish crates to crates.io. The author could be both @huachaohuang and engula/maintainers team if exists.

[tisonkun]

Tasks for a v0.2.0 release are basically:

1. Push a new tag v0.2.0.
2. Create a source release from the tag, and also an announcement about the release (Creating a release, point 10).
3. Publish the crates on crates.io (see also about owners above).

Apart from the release procedure, documents and blogs about how to play with v0.2.0 are admirable.

[huachaohuang]

I am starting a release blog. We may consider adding a simple user manual somewhere. Or put an example to README.

[huachaohuang]

@tisonkun do you know about the docs.rs things? Does it work automatically as long as we publish to crates.io?

[tisonkun]

@huachaohuang I'm not an expert but publishing a new version should automatically create a new version on docs.rs for that crate.

[huachaohuang]

So for user documents, I propose the following two things:

• Add more crate-level documents before release so that users can discover the details when necessary
• Add a "Docs" section on our homepage and provide a simple tutorial about the hash engine and three kernel implementations

[kennytm]

fyi you can check details about how docs.rs build crates in https://docs.rs/about/builds.

[huachaohuang]

I already have a draft for the release post. Does anyone want to help with engula/engula.github.io#16?

[huachaohuang]

The Rust release model looks very reasonable. It is too early for us to follow for now. But I think we can start with using a stable branch for v0.2.

[tisonkun]

@huachaohuang pushing a v0.2.0 tag is necessary to create a permanent release, but a v0.2 branch is very unlikely to have any further (backport) commits, and has nothing to do with "stable" as we're in 0.x versions.

However, create such a branch is lightweight and does no harm no matter whether it gets further commits. So I don't object to do so, but suspect its value.

FYI I've discussed about release branches in #32 (comment).

[huachaohuang]

@tisonkun Oh, thanks for reminding me about the discussion. I agree that "stable" is not appropriate in 0.x. We only need to address one problem for now. We need another branch to hold the commits for the upcoming release so that we can continue the development on the main branch. Otherwise, we have to release whatever we get in the main branch on the release date.

[tisonkun]

@huachaohuang thanks for your explanation. It makes sense to do something like "code freeze" while not blocking main branch evolving. Agree to have such a branch then.

[huachaohuang]

I am going to review the code a little bit, add some comments/documents may be, and create a release branch. Then we can tag the release branch for releases and publish the cargo crates. After that, I will update the posts here accordingly.

[huachaohuang]

I tried to use cargo-workspaces to publish all crates together. It works well.

[tisonkun]

@huachaohuang I notice your recent PRs about release. I'm unfamiliar with cargo yet so that one comment here:

You can collect actions/steps and consideration about the releasing procedure to a release manual as I described here, which will be a good start point to improve the release procedure with peer reviews.

[huachaohuang]

You can collect actions/steps and consideration about the releasing procedure to a release manual as I described here, which will be a good start point to improve the release procedure with peer reviews.

OK, I will write a release guide after I finished release 0.2 (so that I know how things really work).

[huachaohuang]

Close this now and I will describe the release process in #205