diff options
author | Moonchild <moonchild@palemoon.org> | 2022-02-14 10:27:56 +0000 |
---|---|---|
committer | Moonchild <moonchild@palemoon.org> | 2022-02-14 10:27:56 +0000 |
commit | 0f077c28909e6ab4ea59f8a6c224d30f4cb3adb5 (patch) | |
tree | d2caed8d34dceb6c56eaf27cdb594b42e3256555 | |
parent | da27041b04e587fd045729b7e30fb3df9fbe612b (diff) | |
parent | c0b63a690e06f410a61f9df4d1a191c40a8da6cb (diff) | |
download | uxp-RC_20220214.tar.gz |
Merge branch 'master' into releaseRC_20220214
-rw-r--r-- | build/moz.configure/toolchain.configure | 4 | ||||
-rw-r--r-- | docs/CONTRIBUTING.md | 4 | ||||
-rw-r--r-- | docs/GRE Coding Style.md (renamed from docs/UXP Coding Style.md) | 2 |
3 files changed, 5 insertions, 5 deletions
diff --git a/build/moz.configure/toolchain.configure b/build/moz.configure/toolchain.configure index 056c6a9328..1f2b5ecf07 100644 --- a/build/moz.configure/toolchain.configure +++ b/build/moz.configure/toolchain.configure @@ -675,9 +675,9 @@ def compiler(language, host_or_target, c_compiler=None, other_compiler=None, # Check the compiler version here instead of in `compiler_version` so # that the `checking` message doesn't pretend the compiler can be used # to then bail out one line later. - if info.type == 'gcc' and info.version < '4.9.0': + if info.type == 'gcc' and info.version < '7.1.0': raise FatalCheckError( - 'Only GCC 4.9 or newer is supported (found version %s).' + 'Only GCC 7.1 or newer is supported (found version %s).' % info.version) # If you want to bump the version check here search for diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 031ddb9043..c98a76f3bf 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -1,6 +1,6 @@ # Code contribution guidelines
-To make sure code changes remain easy to organize, find and troubleshoot, please use the following guidelines when contributing code to the Pale Moon project (and UXP). These guidelines may, for some of you, sound tedious or more work than you'd prefer to put in, but keep in mind that a single paragraph of explanation with a code commit can save hours of work later on, and code comments can save your hide when trying to debug or improve code.
+To make sure code changes remain easy to organize, find and troubleshoot, please use the following guidelines when contributing code to the Pale Moon project (and GRE). These guidelines may, for some of you, sound tedious or more work than you'd prefer to put in, but keep in mind that a single paragraph of explanation with a code commit can save hours of work later on, and code comments can save your hide when trying to debug or improve code.
## General guideline for issues
@@ -39,7 +39,7 @@ For META issues it is important that discussion about specific implementation pa ## General guideline for submitting pull requests
-Most of our code changes will likely be submitted by collaborators from our community. This will be ported from other projects (e.g. Mozilla-based code) or new implementations, or a mix. The standard way of getting your code into Pale Moon or UXP is by way of creating a pull request against the master branch (trunk).
+Most of our code changes will likely be submitted by collaborators from our community. This will be ported from other projects (e.g. Mozilla-based code) or new implementations, or a mix. The standard way of getting your code into Pale Moon or GRE is by way of creating a pull request against the master branch (trunk).
A good pull request will:
- **Have an issue associated with it!** Even though GitHub offers very similar tools for PRs as it does for issues, any reasoning behind code commits in a PR have to be explained in an accompanying issue.
diff --git a/docs/UXP Coding Style.md b/docs/GRE Coding Style.md index fc025584f0..f863d46a6d 100644 --- a/docs/UXP Coding Style.md +++ b/docs/GRE Coding Style.md @@ -1,4 +1,4 @@ -# UXP Coding Style Guide +# GRE Coding Style Guide While our source tree is currently in a number of different Coding Styles and the general rule applies to adhere to style of surrounding code when you are making changes, it is our goal to unify the style of our source tree and making it adhere to a single style. This document describes the preferred style for new source code files and the preferred style to convert existing files to. |