0.5 release planning

[djc]

Tracking issue for the 0.5 release. Blocking issues:

• Avoid panicking in chrono function calls (see Consider refactoring chrono to avoid systematic misuse of panics #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 (add LocalOffset type that stores the timezone name #750, exploration with the timezone trait #830, Wrong output from %Z specifier when using Local::now().format() #749, Consider new helper methods for LocalResult #716)
• Remove old duration references, timedelta (after Use std duration with NaiveTime #895 etc merged)

Non-blocking:

• Adding Day<Tz> (Rename NaiveDate and potentially remove Date<Tz> #820 / add Day<Tz> #883)
• Const improvements (Making Duration::seconds and similar functions const #638, Changes to naive::internals to enable more const functions #882)
• Use core::time::Duration (Use std duration with NaiveTime #895)
• Improved fuzzing etc (Fix building chrono-fuzz #967, Add chrono-fuzz to CI and update its libfuzzer-sys dependency #968, etc)

[howjmay]

I am curious about the progress of #749

[jtmoon79]

And my PRs around string parsing? 😊

• Issue #660 whitespace exact #807
• Constrain timezone parsing #1000
• Issue 835 timezone offset allow MINUS SIGN (U+2212) (branch main) #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 😄. This is the remaining work that would be very nice to finish up first:

• Refactor of naive::date and naive::internals modules (Refactor internals module #1212, a follow-up that I have split out, and Use NonZeroI32 inside NaiveDate #1207).
• More features for Duration (Make methods on NaiveDateTime const where possible #1286), maybe followed with a rename + alias?
• Make the remaing methods const where possible (Make methods on NaiveDateTime const where possible #1286 and one more follow-up).
• Easy initialization macro's (Add easy initialization macros #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 #1327, and #1286 is quite small I think. I'll work on splitting up the third.