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

0.5 release planning #970

Open
djc opened this issue Feb 20, 2023 · 21 comments
Open

0.5 release planning #970

djc opened this issue Feb 20, 2023 · 21 comments

Comments

@djc
Copy link
Member

djc commented Feb 20, 2023

Tracking issue for the 0.5 release. Blocking issues:

Nice to haves:

  • Opt-in const APIs that allow error checking at compilation
@djc
Copy link
Member Author

djc commented Feb 20, 2023

@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
Copy link
Collaborator

esheppa commented Feb 20, 2023

@howjmay
Copy link

howjmay commented Feb 22, 2023

I am curious about the progress of #749

@jtmoon79
Copy link
Contributor

jtmoon79 commented Apr 5, 2023

@djc
Copy link
Member Author

djc commented Apr 5, 2023

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

@xemwebe
Copy link

xemwebe commented Apr 13, 2023

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
Copy link

kpcyrd commented Apr 14, 2023

@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
Copy link
Member Author

djc commented Apr 14, 2023

@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
Copy link
Contributor

Zomtir commented Apr 14, 2023

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

@xemwebe
Copy link

xemwebe commented Apr 14, 2023

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
Copy link

xemwebe commented Apr 14, 2023

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
Copy link

RagibHasin commented Apr 24, 2023

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
Copy link
Contributor

jtmoon79 commented Jul 9, 2023

@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
Copy link
Member Author

djc commented Jul 24, 2023

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?

crosvm-bot pushed a commit to google/crosvm that referenced this issue Aug 11, 2023
The newest chrono version is currently on the 0.4.x branch, but there
are preparations to release a 0.5.x version. Explicitly specify a 0.4.x
version in our dependencies since there will be backwards-incompatible
API breakages in 0.5.x.
<chronotope/chrono#970>

The exact version chosen (chrono 0.4.19) matches the version we have
pinned in Cargo.lock currently and will match any newer 0.4.x releases,
so there should be no functional change.

BUG=None
TEST=cargo build

Change-Id: Ifa24a547e435ab4987be9358343e6b25c1385c66
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4774870
Commit-Queue: Daniel Verkamp <[email protected]>
Reviewed-by: Dennis Kempin <[email protected]>
@mvntainer
Copy link

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

@djc
Copy link
Member Author

djc commented Aug 17, 2023

See #1095.

@pitdicker
Copy link
Collaborator

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:

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
Copy link
Member Author

djc commented Sep 27, 2023

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
Copy link
Collaborator

For Duration I opened #1327, and #1286 is quite small I think. I'll work on splitting up the third.

@jacobsvante
Copy link

8 months since last update, what's the status today? Does the 0.5 milestone contain what's left to do until release?

@djc
Copy link
Member Author

djc commented Jun 13, 2024

There's still quite a bit of work left to do, and unfortunately not all of that work is captured in the milestone.

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

No branches or pull requests