pub struct VersionCheckCache {
pub latest_version: String,
pub current_version: String,
pub checked_at: DateTime<Utc>,
pub update_available: bool,
pub notified: bool,
pub notification_count: u32,
}Expand description
Cached version information with notification tracking.
This structure stores version check results along with timestamps and notification state to provide intelligent update prompting.
§Fields
latest_version- The latest version string from GitHub releasescurrent_version- The version that was running when cachedchecked_at- UTC timestamp when this information was fetchedupdate_available- Whether an update was available at check timenotified- Whether the user has been notified about this updatenotification_count- Number of times user has been notified
§Serialization
This struct is serialized to JSON for persistent caching between CCPM runs.
Fields§
§latest_version: StringThe latest version string from GitHub releases (e.g., “0.4.0”).
current_version: StringThe version that was running when this cache was created.
checked_at: DateTime<Utc>UTC timestamp when this version information was fetched.
update_available: boolWhether an update was available at the time of check.
notified: boolWhether the user has been notified about this specific update.
notification_count: u32Number of times the user has been notified about this update.
Implementations§
Source§impl VersionCheckCache
impl VersionCheckCache
Sourcepub fn new(current_version: String, latest_version: String) -> Self
pub fn new(current_version: String, latest_version: String) -> Self
Create a new cache entry from version information.
Sourcepub fn is_valid(&self, interval_seconds: u64) -> bool
pub fn is_valid(&self, interval_seconds: u64) -> bool
Check if the cache is still valid based on the given interval.
Sourcepub fn mark_notified(&mut self)
pub fn mark_notified(&mut self)
Mark this update as notified and increment the count.
Sourcepub fn should_notify(&self) -> bool
pub fn should_notify(&self) -> bool
Check if we should notify about this update.
Implements a backoff strategy to avoid notification fatigue:
- First notification: immediate
- Subsequent notifications: with increasing intervals