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

Georges Racinet georges.racinet at octobus.net
Thu Apr 25 09:11:23 EDT 2019


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.

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)

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.

Best,


-- 
Georges Racinet
https://octobus.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190425/d9408bdb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190425/d9408bdb/attachment.sig>


More information about the Mercurial-devel mailing list