How do we keep track of changes waiting on a higher MSRV?

[EliahKagan]

Some changes cannot be made now but are planned for when the minimum supported Rust version is high enough to support them (either to make a language or library feature available, or for it to be stabilized). This includes at least the following:

• Drop once_cell #1518
• use NotADirectory io error kind where appropriate #1775

There may be others such closed PRs. There are also various MSRV-related TODO comments, such as:

gitoxide/gix-fs/src/lib.rs

Lines 90 to 95 in 8df0db2

	/// Return `true` if `err` indicates that the entry doesn't exist on disk. `raw` is used as well
	/// for additional checks while the variants are outside the MSRV.
	pub fn is_not_found(err: ErrorKind, raw_err: Option<i32>) -> bool {
	// TODO: use variant once MSRV is 1.83
	err == ErrorKind::NotFound || raw_err == Some(20)
	}

gitoxide/gix-merge/src/blob/builtin_driver/text/mod.rs

Lines 106 to 108 in 8df0db2

	/// The amount of conflict marker characters to print by default.
	// TODO: use NonZeroU8::new().unwrap() here once the MSRV supports it.
	pub const DEFAULT_MARKER_SIZE: u8 = 7;

How are, or should, such plans be tracked? Comments are one way of tracking them, of course, but there does not always seem to be such a comment, and sometimes a change would touch several places in the code (such as using LazyLock) such that it is no clear ideal place to have a comment about it.

[Byron]

A good point, thanks for bringing it up.

Intuitively, without getting too much into github issues and release planning, I felt that adding categories to TODOs like TODO(category) would help to find related TODOs. I'd think that placing it in one or more strategic positions will help to also discover more, similar items.

Then once could look for all categorised TODO's easily, and in case of the MSRV, one could add a note to the one spot where the MSRV is changed (msrv.yml) to look for TODO(msrv) for instance to see if some of these TODOs can now be resolved.

This would mean that ideally, each TODO has some sort of category. As far as I know, there are two of these already: performance/perf and borrowchk.

[EliahKagan]

Sounds good. I'll try writing categories when writing TODOs, look at and add them to any TODOs I've written in the code that are still around, and also eventually add TODO(msrv) comments for two examples even if I don't do anything else in those parts of the code soon.