Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in the installer's In…

Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=649854
Committed: https://crrev.com/8be2f0889cd2d57cfd9910279e4b2e697aba76f8
Cr-Commit-Position: refs/heads/master@{#423894}

[Sidney San Martín, 2016-09-23 20:35:49]

sdy@chromium.org changed reviewers:
+ rsesek@chromium.org

[Robert Sesek, 2016-09-23 20:58:26]

LGTM. Maybe file a bug to track this and link your other CL to it as well?

[Sidney San Martín, 2016-09-23 22:40:28]

Description was changed from

==========
Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in
the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=
==========

to

==========
Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in
the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=649854
==========

[Sidney San Martín, 2016-09-23 22:40:40]

The CQ bit was checked by sdy@chromium.org

[commit-bot: I haz the power, 2016-09-23 22:41:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-23 22:51:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-23 22:51:09]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Sidney San Martín, 2016-09-26 17:26:23]

sdy@chromium.org changed reviewers:
+ mark@chromium.org, peter@chromium.org

[Sidney San Martín, 2016-09-26 17:27:33]

(Sorry for the empty email! Adding mark@ and peter@ for owner coverage.)

[Mark Mentovai, 2016-09-26 17:39:08]

LGTM, but I note that the hard-code in the app’s Info.plist was a temporary hack
because the real deployment target and the one that we tell the compiler about
had gotten out of sync. Before that, we did use a substitution in Info.plist.

[Sidney San Martín, 2016-09-26 18:43:28]

On 2016/09/26 17:39:08, Mark Mentovai wrote:
> LGTM, but I note that the hard-code in the app’s Info.plist was a temporary
hack
> because the real deployment target and the one that we tell the compiler about
> had gotten out of sync. Before that, we did use a substitution in Info.plist.

From chatting with rsesek@, it sounded like making a build variable to represent
the "effective deployment target" might make the hack seem more legitimate :).
Let me know if there's a better middle ground.

[Peter Beverloo, 2016-09-27 10:13:43]

//content/shell rs lgtm

[Sidney San Martín, 2016-10-07 16:13:33]

The CQ bit was checked by sdy@chromium.org

[commit-bot: I haz the power, 2016-10-07 16:13:50]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Sidney San Martín, 2016-10-07 16:15:49]

The CQ bit was unchecked by sdy@chromium.org

[Sidney San Martín, 2016-10-07 16:33:21]

The CQ bit was checked by sdy@chromium.org

[commit-bot: I haz the power, 2016-10-07 16:33:42]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 17:17:19]

Description was changed from

==========
Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in
the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=649854
==========

to

==========
Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in
the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=649854
==========

[commit-bot: I haz the power, 2016-10-07 17:17:21]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-07 17:20:27]

Description was changed from

==========
Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in
the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=649854
==========

to

==========
Remove LSMinimumSystemVersion from content/shell's Info.plists, hardcode 10.9 in
the installer's Info.plist.

- The ones in content/shell were being stripped out by gen_plist.py
  because nothing is bound to the MACOSX_DEPLOYMENT_TARGET substitution.

- The main app already has this key hard-coded in its Info.plist. From
  talking to rsesek@, using the same pattern for the installer will be
  less confusing than inventing a new build variable, expecially since
  our actual minimum supported version is only temporarily out of sync
  with the "real" build-time deployment target.

BUG=649854

Committed: https://crrev.com/8be2f0889cd2d57cfd9910279e4b2e697aba76f8
Cr-Commit-Position: refs/heads/master@{#423894}
==========

[commit-bot: I haz the power, 2016-10-07 17:20:29]

Patchset 1 (id:??) landed as
https://crrev.com/8be2f0889cd2d57cfd9910279e4b2e697aba76f8
Cr-Commit-Position: refs/heads/master@{#423894}

[Sidney San Martín, 2016-10-07 18:08:49]

On 2016/09/26 17:39:08, Mark Mentovai wrote:
> LGTM, but I note that the hard-code in the app’s Info.plist was a temporary
hack
> because the real deployment target and the one that we tell the compiler about
> had gotten out of sync. Before that, we did use a substitution in Info.plist.

Understood. I talked to rsesek@ about adding a build variable to represent the
min version that we use in Info.plists, but he brought me over to thinking
that's not worth it. I'll hunt these down as soon as the deployment target is
back in sync.