Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time dependency out of date #1277

Closed
OvermindDL1 opened this issue Jun 9, 2021 · 7 comments · Fixed by #1455
Closed

time dependency out of date #1277

OvermindDL1 opened this issue Jun 9, 2021 · 7 comments · Fixed by #1455

Comments

@OvermindDL1
Copy link

The time dependency is currently set to 0.2.16, the latest 0.2 version is 0.2.26, however 0.3.0 has a couple alpha versions out and looks about to be released. I'm using a project where another dependency is using time 0.3.0 latest alpha and I'm unable to pass times between it and sqlx due to the version mismatch. Any chance of either updating time in sqlx to 0.3 alpha or adding a new feature with its support so I don't have to manually (and buggy in some cases) transfer between them?

@abonander
Copy link
Collaborator

You can't have multiple versions of the same crate as a direct dependency, optional or not. And anyway, I don't think we want to link against an alpha release, especially not in a public dependency like time as that would be a breaking change every time we upgrade (necessitating a 0.x.0 -> 0.(x + 1).0 version bump), and alpha releases aren't semver-compatible.

The time dependency is currently set to 0.2.16, the latest 0.2 version is 0.2.26,

Even though we specify a patch release like 0.2.16, because of semver that can automatically update to 0.2.26 or later under 0.2.x without our intervention. By default unless you prefix the version with = it's only a minimum.

@jplatte
Copy link
Contributor

jplatte commented Jun 10, 2021

You can't have multiple versions of the same crate as a direct dependency, optional or not.

This is not true.

And anyway, I don't think we want to link against an alpha release, [...]

How about this? (personally I don't care about the time alpha version, but if I were a maintainer, I'd accept a patch like this)

# unstable feature: may be removed in a non-breaking release
unstable-time03-alpha1 = { package = "time", version = "=0.3.0-alpha-1", optional = true }
#[cfg(feature = "unstable-time03-alpha1")]
impl Type for unstable_time03_alpha1::Date<unstable_time03_alpha1::Utc> { /* ... */ }

@abonander
Copy link
Collaborator

Oh yeah, with a rename you can have multiple of the same crate. My mistake. And all pre-release versions are apparently considered semver-compatible, which is something I keep forgetting: https://doc.rust-lang.org/stable/cargo/reference/resolver.html#pre-releases

Still, I would consider it an antipattern to make an alpha release part of the public API of a non-alpha crate. It looks like a full release of time isn't too far off anyway, so we'll probably just target using time 0.3 for sqlx 0.6.0 (or provide both time-02 and time-03 features, depends on how much of the ecosystem lags behind upgrading): time-rs/time#248 (comment)

@fstephany
Copy link

Time 0.3 has been released. Rocket landed a commit with the upgrade but I don't know if others have catched up yet.

@paolobarbolini
Copy link
Contributor

I might have some time available to work on this, if nobody started looking into it yet...

@tyhi
Copy link
Contributor

tyhi commented Sep 18, 2021

I might have some time available to work on this, if nobody started looking into it yet...

If you haven't started on it I've been working on it this afternoon, running tests and cleaning then should be able to make a PR.

@abonander
Copy link
Collaborator

As it turns out, it's a real pain to support multiple versions of time: #1455 (comment)

It's possible to hack around but the maintenance burden isn't worth it IMO so we're just going to upgrade wholesale to time 0.3 in SQLx 0.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants