Open jonassmedegaard opened 1 week ago
Hey @jonassmedegaard! We already decided to do so. It's just a matter of personal availability to integrate it into CI. See https://github.com/duesee/imap-next/issues/282
Thanks for your work! We will come to it soon!
I'll go ahead and tag the older releases, too. Can probably do in the following days.
Ohh, nice!
Sorry that I didn't investigate first - I sure didn't mean to stress anyone: There is absolutely no rush for my part, it is only a nicety to get notified is all.
No worries! Let's keep this issue open for the time being. When we close you should get a hint :-)
I pushed the tags for v0.1.0
, v0.2.0
, and v0.3.0
. While doing so, I delved a bit into how cargo publish
es crates. I'm sure you are aware of that, but there is no guarantee that the tags pushed on GitHub correlate with the sources on crates.io. In fact, cargo needs to rewrite them a bit. Out of curiosity... what do you actually need the tags for? Is it only for easier reference/usability or do packages rely on GitHub sources technically?
For further releases we'll ensure to have a CI workflow similar to imap-{codec,types}
s. With this flow, we won't publish versions manually anymore but will have a CI job publishing on pushed tags.
I am aware that the code distributed via crates.io is not exactly identical to that at Github. Debian distributes binary code built on Debian infrastructure from preferred-for-upstream-changes sources. This is slightly different from building from crates.io "sources", exactly because of the slight difference between consumer view (what is published at crates.io) and developer view (what is tracked in git).
I use git tags for two things: to help notify when new releases are out, and as basis for syncing upstream sources used for building Debian packages. In principle I could monitor crates.io and fetch from crates.io, but since fetching from crates.io arguably violates the principle of building from "true source", and because the mechanisms for monitoring and fetching are easier done using same source of truth, I tolerate that the source is slightly skewed (e.g. that README file sometimes lack the final polishing done after the git tagging for some projects).
If you ask because of a concern about that skew potentially causing real trouble, please do share your concern.
Thank you for your elaborate answer!
No concerns. I was asking out of curiosity and because I feel that knowing -- at least a bit -- about how this project is used can potentially help me to make better decisions in general.
Release tags in git helps track correspondence between source and distributed code. Personally it would ease my work maintaining the (re)distribution of this nice project as part of Debian.
Please consider tagging releases.