Merge branch 'master' of https://github.com/prebid/Prebid.js

* 'master' of https://github.com/prebid/Prebid.js: (367 commits)
  Rubicon adapter: get referrer from bidderRequest.refererInfo.referer; (prebid#3087)
  Minor freewheel-ssp update (prebid#3119)
  fixes prebid#3128 YieldlabBidAdapter is not using bidRequest.params.adSize (prebid#3129)
  Support Video Renderer (prebid#3104)
  Fix for Issue 3130: passing new copy of adUnits object to every adapter (prebid#3131)
  Add video params to Beachfront adapter (prebid#3121)
  Sonobi - Fix ref encoding (prebid#3125)
  update circleci link to just Prebid.js builds (prebid#3132)
  Bugfix: Issue 3111 (prebid#3122)
  increment prebid version
  Prebid 1.25.0 Release
  adding account to s2s bidder-sync request (prebid#3123)
  Revert "Trafficroots Bid Adapter Submission (prebid#2993)" (prebid#3124)
  Trafficroots Bid Adapter Submission (prebid#2993)
  add versioning and deprecation policy doc (prebid#3103)
  improving kargo unit tests for currency handling (prebid#3106)
  AdOcean adapter improvment (prebid#3011)
  Serverbid Bid Adapter: Add pubnx alias (prebid#3064)
  Adds an id parameter (prebid#3107)
  added sizes for rubicon (prebid#3094)
  ...

Author: Armand Choy

.circleci/config.yml

@@ -0,0 +1,50 @@
+# Javascript Node CircleCI 2.0 configuration file
+#
+# Check https://circleci.com/docs/2.0/language-javascript/ for more details
+#
+version: 2
+jobs:
+  build:
+    docker:
+      # specify the version you desire here
+      - image: circleci/node:7.10
+      
+      # Specify service dependencies here if necessary
+      # CircleCI maintains a library of pre-built images
+      # documented at https://circleci.com/docs/2.0/circleci-images/
+      # - image: circleci/mongo:3.4.4
+
+    working_directory: ~/Prebid.js
+
+    steps:
+      - checkout
+
+      # Download and cache dependencies
+      - restore_cache:
+          keys:
+          - v1-dependencies-{{ checksum "package.json" }}
+          # fallback to using the latest cache if no exact match is found
+          - v1-dependencies-
+
+      - run: npm install
+
+      - save_cache:
+          paths:
+            - node_modules
+          key: v1-dependencies-{{ checksum "package.json" }}
+
+      - run: sudo npm install -g gulp-cli
+      # Download and run BrowserStack local
+      - run:
+          name : Download BrowserStack Local binary and start it.
+          command : |
+            # Download the browserstack binary file
+            wget "https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip"
+            # Unzip it
+            unzip BrowserStackLocal-linux-x64.zip
+            # Run the file with user's access key
+            ./BrowserStackLocal ${BROWSERSTACK_ACCESS_KEY} &
+      # run tests!
+      - run: 
+          name: BrowserStack testing
+          command: gulp test --browserstack

.eslintrc.js

@@ -26,7 +26,6 @@ module.exports = {
     // Violations of these styles should be fixed, and the exceptions removed over time.
     //
     // See Issue #1111.
-    "camelcase": "off",
     "eqeqeq": "off",
     "no-return-assign": "off",
     "no-throw-literal": "off",

.travis.yml

@@ -55,7 +55,7 @@ When you are adding code to Prebid.js, or modifying code that isn't covered by a
 Prebid.js already has many tests. Read them to see how Prebid.js is tested, and for inspiration:
 
 - Look in `test/spec` and its subdirectories
-- Tests for bidder adaptors are located in `test/spec/adapters`
+- Tests for bidder adaptors are located in `test/spec/modules`
 
 A test module might have the following general structure:
 

CONTRIBUTING.md

@@ -0,0 +1,25 @@
+# Prebid versioning and deprecation policy
+
+## Goals
+Provide clear definitions and policy around versioning and breaking changes to APIs that are both publisher and demand partner facing.
+
+ - Limit the number of breaking changes.
+ - Ensure significant time for updates for breaking changes so that publisher or demand partners do not break.
+ - Provide a path to deprecation and reduce technical debt and increase security.
+ - Major versions should not be changed more than once per 30 days.
+
+## Versioning
+
+Follow semantic versioning so that all breaking changes occur within a major release. A breaking change includes both demand partner internal APIs* and publisher facing APIs (global APIs).
+
+*Demand partner APIs may be excluded from breaking change policy at the core teams discretion if the changes are made so to be transparent to the bidders (such as internal refactoring).
+
+## Deprecation process
+
+ - Open an issue with an "intent to implement" and "API impact" labels.
+ - Allow 2 weeks for discussion.
+ - Announce breaking change to the mailing list (TBD needs to be created).
+ - At least 2 core members needs to provide explicit approval for the deprecation.
+ - Open a PR against current master for console warning for possible breakage.
+ - Support the previous major version for a minimum of 30 days.
+ - Coordinate with the core team to ensure clean merging into feature branch if applicable (future major version branch).

PREBID_VERSIONING_DEPRECATION.md

@@ -18,6 +18,7 @@ For modules and core platform updates, the initial reviewer should request an ad
 - Once there is 2 `LGTM` on the PR, merge to master
 - Ask the submitter to add a PR for documentation if applicable.
 - Add a line into the [draft release](https://github.com/prebid/Prebid.js/releases) notes for this submission. If no draft release is available, create one using [this template]( https://gist.github.com/mkendall07/c3af6f4691bed8a46738b3675cb5a479)
+- Add the PR to the appropriate project board (I.E. 1.23.0 Release) for the week, [see](https://github.com/prebid/Prebid.js/projects)
 
 ### New Adapter or updates to adapter process
 - Follow steps above for general review process. In addition, please verify the following:
@@ -39,9 +40,9 @@ For modules and core platform updates, the initial reviewer should request an ad
 ## Ticket Coordinator
 
 Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. That person should:
-- Review issues and PRs at least once per weekday for new items.
+- Review issues and PRs at least once per weekday for new items. Encourage a 48 "SLA" on PRs/issues assigned. Aim for touchpoint once every 48/hours. 
 - For PRs: assign PRs to individuals on the PR review list. Try to be equitable -- not all PRs are created equally. Use the "Assigned" field and add the "Needs Review" label.
-- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed.
+- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed. Please add labels as appropriate (I.E. bug, question, backlog etc).
 - Issues that are questions or troubleshooting requests may be closed if the originator doesn't respond within a week to requests for confirmation or details.
 - Issues that are bug reports should be left open and assigned to someone in PR rotation to confirm or deny the bug status.
 - It's polite to check with others before assigning them large tasks.

PR_REVIEW.md

@@ -1,9 +1,10 @@
-[![Build Status](https://travis-ci.org/prebid/Prebid.js.svg?branch=master)](https://travis-ci.org/prebid/Prebid.js)
+[![Build Status](https://circleci.com/gh/prebid/Prebid.js.svg?style=svg)](https://circleci.com/gh/prebid/Prebid.js)
 [![Percentage of issues still open](http://isitmaintained.com/badge/open/prebid/Prebid.js.svg)](http://isitmaintained.com/project/prebid/Prebid.js "Percentage of issues still open")
 [![Average time to resolve an issue](http://isitmaintained.com/badge/resolution/prebid/Prebid.js.svg)](http://isitmaintained.com/project/prebid/Prebid.js "Average time to resolve an issue")
 [![Code Climate](https://codeclimate.com/github/prebid/Prebid.js/badges/gpa.svg)](https://codeclimate.com/github/prebid/Prebid.js)
 [![Coverage Status](https://coveralls.io/repos/github/prebid/Prebid.js/badge.svg)](https://coveralls.io/github/prebid/Prebid.js)
 [![devDependencies Status](https://david-dm.org/prebid/Prebid.js/dev-status.svg)](https://david-dm.org/prebid/Prebid.js?type=dev)
+[![Total Alerts](https://img.shields.io/lgtm/alerts/g/prebid/Prebid.js.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/prebid/Prebid.js/alerts/)
 
 # Prebid.js
 
@@ -29,6 +30,8 @@ Working examples can be found in [the developer docs](http://prebid.org/dev-docs
     $ npm install
 
 *Note:* You need to have `NodeJS` 4.x or greater installed.
+*Note:* Because we have transitioned to using gulp 4.0 - you need to have `gulp-cli` installed globally prior to running the general `npm install`.  Run the following command to perform the install: `npm install gulp-cli -g`
+If you have a previous version of `gulp` installed globally, you'll need to remove it before installing `gulp-cli`.  This removal can be done with the command: `npm rm gulp -g`
 
 <a name="Build"></a>
 
@@ -106,11 +109,6 @@ To run the unit tests:
 ```bash
 gulp test
 ```
-To run tests for a single file:
-
-```bash
-gulp test --file "path/to/spec/file.js"
-```
 
 To generate and view the code coverage reports:
 
@@ -172,7 +170,7 @@ Many SSPs, bidders, and publishers have contributed to this project. [60+ Bidder
 
 For guidelines, see [Contributing](./CONTRIBUTING.md).
 
-Our PR review process can be found [here](https://github.com/prebid/Prebid.js/tree/master/pr_review.md).
+Our PR review process can be found [here](https://github.com/prebid/Prebid.js/tree/master/PR_REVIEW.md).
 
 ### Add a Bidder Adapter
 

README.md

@@ -1,4 +1,10 @@
-# Release Schedule
+**Table of Contents**
+- [Release Schedule](#release-schedule)
+- [Release Process](#release-process)
+- [Beta Releases](#beta-releases)
+- [FAQs](#faqs)
+
+## Release Schedule
 
 We push a new release of Prebid.js every other week on Tuesday. During the adoption phase for 1.x, we are releasing updates for 1.x and 0.x at the same time.
 
@@ -9,7 +15,118 @@ You can determine what is in a given build using the [releases page](https://git
 
 Announcements regarding releases will be made to the #headerbidding-dev channel in subredditadops.slack.com.
 
-# FAQs
+## Release Process
+
+_Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for your repo, all of the following git commands will have to be modified to reference the proper remote (e.g. `upstream`)_
+
+1. Make Sure all browserstack tests are passing. On PR merge to master CircleCI will run unit tests on browserstack. Checking the last CircleCI build [here](https://circleci.com/gh/prebid/Prebid.js) for master branch will show you detailed results. 
+  
+   In case of failure do following, 
+     - Try to fix the failing tests.
+     - If you are not able to fix tests in time. Skip the test, create issue and tag contributor.
+
+   #### How to run tests in browserstack
+   
+   _Note: the following browserstack information is only relevant for debugging purposes, if you will not be debugging then it can be skipped._
+
+   Set the environment variables. You may want to add these to your `~/.bashrc` for convenience.
+
+   ```
+   export BROWSERSTACK_USERNAME="my browserstack username"
+   export BROWSERSTACK_ACCESS_KEY="my browserstack access key"
+   ```
+   
+   ```
+   gulp test --browserstack >> prebid_test.log
+   
+   vim prebid_test.log // Will show the test results
+   ```
+
+
+2. Prepare Prebid Code
+
+   Update the package.json version to become the current release. Then commit your changes.
+
+   ```
+   git commit -m "Prebid 1.x.x Release"
+   git push
+   ```
+
+3. Verify Release
+
+   Make sure your there are no more merges to master branch. Prebid code is clean and up to date.
+
+4. Create a GitHub release
+
+   Edit the most recent [release notes](https://github.com/prebid/Prebid.js/releases) draft and make sure the correct tag is in the dropdown. Click `Publish`. GitHub will create release tag. 
+   
+   Pull these changes locally by running command 
+   ```
+   git pull
+   git fetch --tags
+   ``` 
+   
+   and verify the tag.
+
+5. Update coveralls _(skip for legacy)_
+
+   We use https://coveralls.io/ to show parts of code covered by unit tests.
+
+   Set the environment variables. You may want to add these to your `~/.bashrc` for convenience.
+   ```
+   export COVERALLS_SERVICE_NAME="travis-ci"
+   export COVERALLS_REPO_TOKEN="talk to Matt Kendall"
+   ```
+
+   Run `gulp coveralls` to update code coverage history.
+
+6. Distribute the code 
+
+   _Note: do not go to step 7 until step 6 has been verified completed._
+
+   Reach out to any of the Appnexus folks to trigger the jenkins job.
+
+   // TODO 
+   Jenkins job is moving files to appnexus cdn, pushing prebid.js to npm, purging cache and sending notification to slack.
+   Move all the files from Appnexus CDN to jsDelivr and create bash script to do above tasks.
+
+7. Post Release Version
+   
+   Update the version
+   Manually edit Prebid's package.json to become "1.x.x-pre" (using the values for the next release). Then commit your changes.
+   ```
+   git commit -m "Increment pre version"
+   git push
+   ```
+   
+8. Create new release draft
+
+   Go to [github releases](https://github.com/prebid/Prebid.js/releases) and add a new draft for the next version of Prebid.js with the following template:
+```
+## 🚀New Features
+ 
+## 🛠Maintenance
+ 
+## 🐛Bug Fixes
+```
+
+## Beta Releases
+
+Prebid.js features may be released as Beta or as Generally Available (GA).
+
+Characteristics of a `Beta` release:
+- May be a partial implementation (e.g. more work needed to flesh out the feature)
+- May not be fully tested with other features
+- Limited documentation, focused on technical aspects
+- Few users
+
+Characteristics of a `GA` release:
+- Complete set of functionality
+- Significant user base with no major issues for at least a month
+- Decent documentation that includes business need, use cases, and examples
+
+
+## FAQs
 
 **1. Is there flexibility in the 2-week schedule?**
 

RELEASE_SCHEDULE.md

@@ -62,21 +62,5 @@
     "browser_version": "8.0",
     "device": null,
     "os": "OS X"
-  },
-  "bs_ios_9": {
-    "base": "BrowserStack",
-    "os": "ios",
-    "os_version": "9.1",
-    "browser": "iphone",
-    "device": "iPhone 6S",
-    "browser_version": null
-  },
-  "bs_ios_8": {
-    "base": "BrowserStack",
-    "os": "ios",
-    "os_version": "8.3",
-    "browser": "iphone",
-    "device": "iPhone 6",
-    "browser_version": null
   }
 }

browsers.json

@@ -2,10 +2,10 @@
 
 This document describes the governance model for the Prebid project. The Prebid project’s stated mission is to facilitate fair, transparent, and effective header bidding across the industry, and is responsible for creating and maintaining such projects as [Prebid.js](https://github.com/prebid/Prebid.js).
 
-1.	A single Tech Lead oversees the technical direction of the project and appoints Core Team members
+1.	A single Tech Lead (PMC Chair) oversees the technical direction of the project and appoints Core Team members
 2.	The Core Team members maintain the project on an ongoing basis with direction from the Tech Lead.
 3.	In the event of any disagreements, the Tech Lead will make a final decision.
-4.	If there is no Tech Lead available to perform his/her duties, AppNexus Inc. will appoint one.
+4.	If there is no Tech Lead available to perform his/her duties, Prebid.org will appoint one.
 
 ### Roles and Responsibilities:
 - **User:** Any individual who consumes / uses the Prebid.js library.
@@ -15,9 +15,9 @@ This document describes the governance model for the Prebid project. The Prebid
 
 ### Current Prebid.js Core Team
 - @mkendall07 (Tech Lead)
-- @protonate
+- @jsnellbaker
 - @matthewlane
 - @jaiminpanchal27
 - @snapwich
 - @harpere
-- @dbemiller
+- @mike-chowla