On 11.03.2012 15:17, Andreas Born wrote: > Am 11.03.2012 15:07, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >> On 11.03.2012 14:55, Andreas Born wrote: >>> In 1.98 there was that export issue, I already mentioned. When opening >>> a new context with configfile e.g. variables were exported to the new >>> context, but not marked anymore for reexport. So you had to reexport >>> them yourself. No way I'm maintaining a workaround for that. >> What do you think of possibility >> if [ x$feature_bug1_fixed != xy -o x$feature_bug2_fixed != xy ]; then >> echo "Too old" >> <basic menu> >> else >> <complete version> >> fi > That's a possibility and how I probably would have used it. But it's > still hard to decide which bugs get a feature and which not. For > features it's similar, but probably a bit easier. >> >> We probably need a feature feature_200_release anyway since it will be >> starting point for most of backward compatibility (compatibility is >> loose with 1.99). >> Perhaps feature_20x_release is the way to go. > 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. > Thanks for your thoughts. > > Andreas > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
