rfcs: add move_itm_crate by tmplt · Pull Request #589 · rust-embedded/wg (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation18 Commits5 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Thank you for the RFC. I'd be happy move ahead with this, but let's hear from the other @rust-embedded/tools members.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Oops. That is unexpected ... but correct.
For sake of transparency: if and when this goes though the repository will be moved to https://github.com/rtic-scope/itm (updated repo already available; so only the crates.io registery entry is necessary at this point) because of its design towards RTIC Scope. I'll amend the RFC if required.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a slight preference to not abandon itm
and rather encourage its development by new contributors inside the WG, but a stronger preference that it gets developed at all, so on balance I'm in favour here. I look forward to welcoming the crate back one day!
@thalesfragoso, any thoughts?
tmplt mentioned this pull request
Sorry for taking too long, I've been a bit busy...
Anyways, isn't it better to just move ownership of the crate's name and archive rust-embedded/itm
(with a link to rtic-scope/itm
) ?
I would also like that a new published version of itm
to be semver incompatible with the current one and to have a note in the README stating that an ownership transfer happened.
Thanks for the work @tmplt and sorry for being a drag...
would also like that a new published version of
itm
to be semver incompatible with the current one
A v0.4.0
has been tagged and is queued for publication. A note can be added to the README.md
sure, but do we do anything with the previous releases? Do we pull them?
Anyways, isn't it better to just move ownership of the crate's name and archive rust-embedded/itm (with a link to rtic-scope/itm) ?
I'd be fine with this approach too, I guess you're right and there might not be much point transferring this repo only to merge a PR that essentially replaces all the code. We could archive this one for reference in the future and just allow the new crate to be published as a semver-incompatible version on top. What do you think @tmplt?
do we do anything with the previous releases? Do we pull them?
I don't think there's any need to pull them. It won't do anything to current users anyway, and it's not like there's some security issue in the older versions.
We could archive this one for reference in the future and just allow the new crate to be published as a semver-incompatible version on top. What do you think?
Sounds good to me. But what is a semver-incompatible version? A release above 0.3.X
?
But what is a semver-incompatible version? A release above 0.3.X?
Yes, 0.4.0 would be fine.
Should the RFC be amended with the following:
- archive
rust-embedded/itm
with a deprecation notice instead of moving it; and - only move the
itm
crates.io registery ownership?
Co-authored-by: Daniel Egger daniel@eggers-club.de
RFC amended: it now proposes archiving rust-embedded/itm
instead of disowning it, and giving me publisher access to itm on crates.io after which itm v0.4.0
will be released.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As approved by the team and discussed in the meeting today, this is good to go and will be put in effect immediately.
Thanks @tmplt.
bors r+
tmplt mentioned this pull request