Support for rolling release versions
Lonami opened this issue · 5 comments
Currently the versions can be unknown, semver or custom:
Would it make sense for it to support rolling too, or is this too rare? I found that as the BUILD_ID in Arch Linux.
It is an interesting question, thanks for pointing it out. How do you think a rolling release version should be represented? As Rolling(date)?
I was thinking just Rolling,, given this:
$ cat /etc/os-release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinuxNote in particular this line:
BUILD_ID=rollingI'm not sure if other operative systems with "rolling" have a date.
This would also be a breaking change, because so far the version is exhaustive.
Honestly I'm not very accustomed with the rolling versioning. I was thinking that even with rolling releases I still can have not the latest version. In that case it can be useful to know how old my operating system is. I guess the date can be extracted from somewhere (from pacman?), but I'm not sure how useful and hard that will be. Still I'm thinking about Rolling(Option<Date>).
I'm OK with the breaking change and releasing a 3.0 version. Additionally #178 can be included into it.
I'm not sure how deep into the rabbit hole the library wants to go. Probably every operating system has its own perks and locations where one could find valuable information to provide that level of detail, but then things get harder to maintain and test. My original idea was just detecting "rolling" as rolling release, but adding the date as an optional value may not be a bad idea.
I'm not sure how deep into the rabbit hole the library wants to go.
I'm not sure either. 🙃
But I would like to add more flexibility for future changes, especially if we are already talking about breaking changes.