If you're going to have a version string, perhaps more granularity over the major.minor would be good to have, perhaps even using the bzr commit number. It would make tracking bugs easier from users as well.
--S On Mar 11, 2012, at 7:58 AM, Andreas Vogel <[email protected]> wrote: > Am 11.03.2012 15:20, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >> On 11.03.2012 15:17, Andreas Born wrote: >>> Yes, that would be fine with me too. I thought about that too, but >>> actually I didn't quite see the difference between this and >>> grub_version or grub_version_min. >>> Maybe there could be: >>> - feature_200_release: or whatever the version is if somebody >>> really only wants to test/support that one version >>> - feature_20x_release: or whatever appropriate for a series of >>> releases where it's possible to be backwards compatible >>> >> feature_*_release wouldn't be removed for the next release. > The feature_* variables are great. Anyway I support Andreas suggestion > having a GRUB version variable (like many other interpreters/shells are > using it, e.g. BASH, Perl, TCL). > BASH is using 2 variables for it: BASH_VERSION and BASH_VERSINFO. The > second one provides an easy way to get the version, sub-version, etc. > (and eliminates the problems with parsing Andreas was mentioning > before). GRUB could provide something similar, but that's just a thought > which came up right now. > > > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
