From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S6jeC-00077Y-Qi for mharc-grub-devel@gnu.org; Sun, 11 Mar 2012 10:21:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jds-00076s-Bv for grub-devel@gnu.org; Sun, 11 Mar 2012 10:21:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6jdq-00070X-DF for grub-devel@gnu.org; Sun, 11 Mar 2012 10:20:59 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:47055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jdq-0006zy-1t for grub-devel@gnu.org; Sun, 11 Mar 2012 10:20:58 -0400 Received: by werj55 with SMTP id j55so3068359wer.0 for ; Sun, 11 Mar 2012 07:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=AM8MfxeX177lFooiJZrdK6nejrnXE2FyY3M2bBcTung=; b=Q3WtF3sQkZBGLcu/zdn2mUeNcFehVEV221XB6oQx9r9VBnYhyK+4r8ZpiNksvCePlB OCPGsS5VZkdwX34EDew1TuTpKsArt4me2COPCFvK0xq54xhiZLQLdcJw2zB9BmbHPogu Dh/LRDYmFqzkU35UkvEU+Gy5xAjQ6RdEKdrUiMytrK0H8a2sGVcpgFLGN2TLnxr2K8lo GVl+GE4WxYzI5AqOap3iLkLi/HiG88oTHAHcfWNoqC7ZLJJythuKvsIQt0g5C6C0Y/VN dnDYmTc7tucScbHRH303UkoDTFG+S4+t1dq/l3GSjfk/mnBbJ/hkA8y5e0275H0Bqrwa Mcrg== Received: by 10.180.78.6 with SMTP id x6mr19702917wiw.18.1331475655822; Sun, 11 Mar 2012 07:20:55 -0700 (PDT) Received: from fedora.x201.phnet (104-9.203-62.cust.bluewin.ch. [62.203.9.104]) by mx.google.com with ESMTPS id fb2sm24659788wid.3.2012.03.11.07.20.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 07:20:54 -0700 (PDT) Message-ID: <4F5CB4C1.4070400@gmail.com> Date: Sun, 11 Mar 2012 15:20:49 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Grub version variable in shell References: <4F5C10A0.1060802@googlemail.com> <4F5C1321.1050403@gmail.com> <4F5C920D.7070808@googlemail.com> <4F5C9ECF.5010707@gmail.com> <4F5CAEBE.3060905@googlemail.com> <4F5CB18D.9070506@gmail.com> <4F5CB3F3.1000806@googlemail.com> In-Reply-To: <4F5CB3F3.1000806@googlemail.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9C46805DDB2945EE2CB2AE18" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 14:21:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9C46805DDB2945EE2CB2AE18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11.03.2012 15:17, Andreas Born wrote: > Am 11.03.2012 15:07, schrieb Vladimir '=CF=86-coder/phcoder' Serbinenko= : >> On 11.03.2012 14:55, Andreas Born wrote: >>> In 1.98 there was that export issue, I already mentioned. When openin= g >>> 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 !=3D xy -o x$feature_bug2_fixed !=3D xy ]; t= hen >> echo "Too old" >> >> else >> >> 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 > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig9C46805DDB2945EE2CB2AE18 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk9ctMIACgkQNak7dOguQglmAAD9GJzT1PTvbjOmE+dhnzrYNoHR 2EyhUpdacAOdwCMKna0BAI3TbjO11PaqtOMIGAypDwT8HA1loVvrAgLXmHp/U/vc =WsPd -----END PGP SIGNATURE----- --------------enig9C46805DDB2945EE2CB2AE18--