0.5 release planning

[djc]

Tracking issue for the 0.5 release. Blocking issues:

• Avoid panicking in chrono function calls (see #815)
  • Rename fallible constructors etc to try_()
  • In general, review _opt() APIs to consider renaming to try_() and use Result instead of Option
• Replace TimeDelta with a thin wrapper around core::time::Duration

Nice to haves:

• Opt-in const APIs that allow error checking at compilation

[djc]

@esheppa anything I forgot? We should probably start linking to specific issues/PRs that we need to get in, divided in two categories: blocking (semver-incompatible changes) and non-blocking (API additions and internal changes).

[esheppa]

There are quite a few attached to the 0.5 milestone as well, including:

Blocking:

• Timezone system changes (#750, #830, #749, #716)
• Remove old duration references, timedelta (after #895 etc merged)

Non-blocking:

• Adding Day<Tz> (#820 / #883)
• Const improvements (#638, #882)
• Use core::time::Duration (#895)
• Improved fuzzing etc (#967, #968, etc)

[howjmay]

I am curious about the progress of https://github.com/chronotope/chrono/issues/749

[jtmoon79]

And my PRs around string parsing? 😊

• https://github.com/chronotope/chrono/pull/807
• https://github.com/chronotope/chrono/pull/1000
• https://github.com/chronotope/chrono/pull/1001

[djc]

No need to mention PRs that have already been merged. 🙂

[xemwebe]

Is there any topic where you would welcome some help to speed things up to proceed on the 0.5 release?

I maintain a couple of crates which depend on chrono and felt some pressure from users to switch to the time crate due to the vulnerability problems of the latest official release, but I really don't like its interface.

Therefore, I believe my time would be better spend to improve chrono instead of switching to time.

[kpcyrd]

@xemwebe that's a very common problem at this point, you can avoid the vulnerable time dependency of chrono 0.4 like this:

cargo add chrono --no-default-features -F clock

As soon as any crate in your dependency tree depends on chrono with default features it's going to pull in time 0.1 again though.

[djc]

@xemwebe in general, help with all the things already mentioned above would be welcome. I want to make structured attempt to avoid panics and expose fallible API instead in 0.5. Maybe start by having a look at things like #1010 and #974?

[Zomtir]

I hope #996 avoids many of those panics; or at least lays the groundwork. Feedback is welcome!

[xemwebe]

Thanks for the hints, I will probably have a look at #996 with respect to #1010 and #974 to see if I can be of any help.

[xemwebe]

Since @Zomtir focuses on constructors, I would work on prusti issues not related to constructors (i.e. basically #974). However, I have checked a few of the detected issues and most of them seems to be false positive, i.e. the detected potential overflow could never happen after careful check of the parameters involved. How would you like to deal with these cases? Just add some comment? Mark these function as #[trusted] might go to far if the function is not trivial.

[RagibHasin]

Nice to haves:

• Opt-in const APIs that allow error checking at compilation

I think const constructors are a necessary feature, not just a nice-to-have. Without const constructors constants in trait need to be worked around using UNIX timestamps everywhere these are used which is very cumbersome.

If there is some way I can help with the design or implementation of const API, I would be very happy to help.

[jtmoon79]

@djc @pitdicker is there a similar "Planning" Issue for the 0.4.x branch? Could/should there be?

There's so much great work that @pitdicker has completed and has ongoing. I'd love to find out when I can try it out in my log reading project. 😊 Also, I know #1073 is highly anticipated.

[djc]

We can certainly have a 0.4.27 planning issue. Is there any particular PR that's not part of 0.4.26 that you're looking forward to?

[mvntainer]

Are there any plans to release a fix for the CVE?

[djc]

See #1095.

[pitdicker]

I would like to start working on 0.5 in earnest in the next couple of weeks. But I really want to avoid some ugly merge conflicts with open PRs, which touch all the same lines as I plan to change in the first couple of commits.

We made great progress this week :smile:. This is the remaining work that would be very nice to finish up first:

• Refactor of naive::date and naive::internals modules (https://github.com/chronotope/chrono/pull/1212, a follow-up that I have split out, and https://github.com/chronotope/chrono/pull/1207).
• More features for Duration (https://github.com/chronotope/chrono/pull/1286), maybe followed with a rename + alias?
• Make the remaing methods const where possible (https://github.com/chronotope/chrono/pull/1286 and one more follow-up).
• Easy initialization macro's (https://github.com/chronotope/chrono/pull/1270, and a follow-up that should make our test cleaner).

Other open PRs will give much less trouble.

For 0.5 I would like to start with removing everything deprecated, rename all the methods that now end with _opt, and convert them to Results (little by little).

Does this sound like a plan?

[djc]

I'm on board with the first three of your bullet items, not as convinced of the macros. Why do we need them before we move on 0.5? Let's start with the first three, and please split them up into smaller PRs so I can digest them more easily.

[pitdicker]

For Duration I opened https://github.com/chronotope/chrono/pull/1327, and https://github.com/chronotope/chrono/pull/1286 is quite small I think. I'll work on splitting up the third.