Publish on crates.io about pelikan HOT 5 OPEN

segcache storage crate has been published

from pelikan.

Some additional notes on this:
src/core/waker - moved to rustcommon, published as awaken

from pelikan.

Some additional questions/notes:

• Do we want to version all of the related pelikan-* crates in lockstep? If not, what is the versioning policy?
• We should probably reserve the pelikan crate too - maybe as a virtual "install all the binaries" crate
• Do we intend for the various storages to be useful as standalone libraries? (e.g. for segcache) If so, we'll probably want to do a second pass over them so they are useful.
• With this many crates being managed in the repo we will probably want some automation to handle the publishing work. There are tools for this and we should look into using them.
• Owner on crates.io - we should probably make a crates.io user for the pelikan foundation, that way we can either have publishing go through github actions or have a team with publishing permissions.

from pelikan.

@swlynch99 - great questions

• I think we should move from the unified version for the workspace back to version per crate. It's going to make the version number meaningful for the individual binaries. We'll do semver for everything, current plan would be to release each as 0.3.2 (next up from current 0.3.1). https://semver.org/#semantic-versioning-specification-semver
• great idea, i'll grab that now with a 0.0.0 namesquatting crate
• yes, individual storage libraries should be useful in other projects. eg 'seg' storage should be usable within another application or library. I believe the 'seg' crate is already in good shape for this, but we'll take another pass across everything and improve docs/ergonomics
• if you have suggestions, please share. I personally didn't love cargo-release when I last used it to contribute to an org repo. If we don't know yet, I'll try to see what other large projects are doing.
• yes, we'll also want to figure a plan for RPMs, DEBs, etc where appropriate

from pelikan.

This work would make it easier to embed Pelikan (and especially segcache) in other services! 👍 Thank you so much for considering that!

When you get to this work, could you please consider reviewing the dependency chains in Pelikan? Namely, today: seg depends on (pelikan-)common which depends on boring (--> boring-sys) and (pelikan-)net. These introduce indirect dependencies that shouldn't be required to use segcache.
#89 tackled this last point ^

from pelikan.