Comments (10)
Hi @jhpratt
It's unfortunately not only CI thing for time
crate. It affects dependent code in case of running coverage checks by llvm-cov
, so it would be great to have a new version with fixed behavior.
from time.
Thanks for the info; I wasn't aware it was changing syntax. Ultimately it's only a CI thing, as it is opt-in. Given that, I'll get around to updating it in the coming days as it's not urgent.
from time.
Yes, for sure. I don't expect any "guarantees" related to this feature. It's just pretty common way to use llvm-cov
under nightly
compiler, because no_coverage/coverage(off)
is still nightly feature.
I'm wondering why it's not possible to make minor (patch) release to solve the issue for nightly builds?
It would be helpful. You can see that there are several GH issues(and these are only public ones) already referred to this one, and most of them had to disable coverage step for a while.
Regardless of the decision, I do appreciate all your efforts to maintain the time
crate. Thank you!
from time.
Caused by rust-lang/rust#114656
from time.
I will point out that coverage_nightly
is only passed on nightly as the name implies. There are no stability guarantees when using nightly — including from time
. There is currently not a release planned, as I still have a few things I want to wrap up before that will occur.
from time.
I'm wondering why it's not possible to make minor (patch) release to solve the issue for nightly builds?
Pretty much as I said — there's a couple things that aren't complete that I want to include. They're pretty minor and as such shouldn't take too long, but that's the reason.
from time.
That doesn't feel like a satisfying answer to me. The time crate has been breaking a bunch of downstream CI setups, a PR was submitted with a fix 5 days ago, and semver-compatible releases ought to be cheap. You could presumably have published this fix and held back your "couple things" for another semver-compatible release?
from time.
As I said, if you're using nightly, breakage is expected. I do not create releases solely to fix something that happens only on nightly. I am working on other things at the moment and will create a release when I feel it is appropriate. I'm not going to be pressured into anything. If it is affecting companies' CI, they are free to sponsor me to ensure that I have more time to work on things.
from time.
TBH, it's hard to understand.
There is a simple win-win strategy here, make a semver compatible release and solve problems for many users. In turn, this will save you from the need to answer the same questions or argue.
Especially considering that the fix was already done by an external contributor, but it turns out that people must either turn off their CI or patch the version themselves.
In addition, it's not only about companies' CI, it affects other open source projects as well where coverage is kinda important
from time.
There's no point in me reiterating the same thing over and over. Locking this issue.
from time.
Related Issues (20)
- PrimitiveDateTime does not parse with insufficient information HOT 4
- Breaking change wish-list HOT 9
- local-offset feature is leaking memory on Apple platforms HOT 2
- Compilation error for "wasm-bindgen"
- Compile error with version 0.3.32 when compiling for wasm32-unknown-unknown HOT 1
- fn OffsetDateTime::date_time(self) if private HOT 1
- Optional weekday for rfc2822 HOT 2
- year repr:last_two removed in 0.3.x? HOT 1
- Optional leading zeros and parsing HOT 3
- Implement `FromStr` for `PrimitiveDateTime` and `OffsetDateTime` HOT 1
- `subsec_{milli,micro,nano}seconds` may have over-inclusive documented ranges HOT 1
- Default `impl Deserialize`/`impl Serialize for time::OffsetDateTime` is a footgun HOT 1
- Mark the date_time function from OffsetDateTime as public HOT 1
- Bug with leap second parsing ISO 8601 HOT 6
- Renaming of `FormatItem` is a breaking change HOT 5
- How to use `serde::format_description` with `format_description::well_known` ? HOT 5
- Confusing deprecation message for `time::Instant` HOT 3
- Formatting bug on ISO8601 HOT 6
- Make `format` methods localizable HOT 6
- Error with rust-nightly: type annotations needed for `Box<_>` HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from time.