[PATCH 1 of 2] rust: published the three extension crates to crates.io

[Yuya Nishihara]

On Thu, 25 Apr 2019 15:11:23 +0200, Georges Racinet wrote:
> On 4/23/19 2:36 PM, Yuya Nishihara wrote:
> >> Besides third party dependencies to hg-core or even hg-cpython
> >> appearing, here's a reason for them not being purely internal:
> >> downstream packagers may need to rely on the crates.io version as per
> >> their policies or tooling capabilities.
> > Do we plan to provide a Rust library? I'm not against to if that's worth
> > the cost. I just feel it's too early.
> >
> Well actually, yes, at least for hg-core.
> 
> For instance, this work of Valentin (added Cc) on a Rust hg status would
> probably benefit to cargo-depend on hg-core soon :
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-February/128768.html
> 
> Another case where I'd imagine it to be useful that hg-core version on
> crates.io would be consistent with released hg versions is for third
> party extensions. I've already taken a serious look at treedirstate, and
> would like to bring it to the core at some point. I'm not sure how I'll
> proceed, but being able in intermediate steps to simply depend onto the
> hg-core from crates.io would be an interesting option.

Okay, then, how about releasing only the hg-core crate? IIRC, the cpython
bridge connects to Mercurial over C API, which means there's no guarantee
that the released crate will work flawlessly with the system Mercurial.
And the direct-ffi should be removed hopefully soon.

> In general, I agree that our Rust code is not stable enough for people
> to rely it without a strong coordination with us, and the version number
> should reflect that, but such strong coordination cases do exist.
> 
> About the version number, I reached a conclusion (could elaborate on it
> later on):
> 
>     Mercurial x.y.z would correspond to hg-core 0.xy.z  (example: 4.9.1
> -> 0.49.1)

Sure it seems less scary than hg-core x.y.z (which means we can't change
the API until hg-core x+1.0.0.) I don't know if the crate version should
look similar to the Mercurial version.

> I understand all this is probably a complication in the release process,
> though, and I'm ready to help if needed. Maybe I could upload crates
> corresponding to Mercurial 5.0 manually ? I don't think it would harm
> the ecosystem, I'd just have to submit a bump of the version numbers in
> our source tree after that.
> 
> In any case, I don't want to overwork the release team, and I'd
> understand if you'd would postpone all of this for the 5.1 timeframe,
> hoping we could sort this out IRL during the sprint. I would certainly
> put it on the agenda.