Introducing Label element into AdaptationSet

Introducing Label element into AdaptationSet

v3.0.2

How to Update

# go get -u github.com/zencoder/go-dash/v3@v3.0.2
go: downloading github.com/zencoder/go-dash/v3 v3.0.2
go get: upgraded github.com/zencoder/go-dash/v3 v3.0.1 => v3.0.2

What's Changed

• Configure WhiteSource for GitHub.com by @whitesource-for-github-com in #89
• Export makePSSHBox by @hikeh in #90
• add attrPublishTime, as publishTime must be present for @type='dynamic' by @liuyanhit in #84

New Contributors

• @whitesource-for-github-com made their first contribution in #89
• @hikeh made their first contribution in #90
• @liuyanhit made their first contribution in #84

Full Changelog: v3.0.1...v3.0.2

First Go Modules release

From: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Note that if you are adopting modules for the first time for a pre-existing repository or set of packages that have already been tagged v2.0.0 or higher before adopting modules, then the recommended best practice is to increment the major version when first adopting modules.

For example, if you are the author of foo, and the latest tag for the foo repository is v2.2.2, and foo has not yet adopted modules, then the best practice would be to use v3.0.0 for the first release of foo to adopt modules (and hence the first release of foo to contain a go.mod file).

Incrementing the major version in this case provides greater clarity to consumers of foo, allows for additional non-module patches or minor releases on the v2 series of foo if needed, and provides a strong signal for a module-based consumer of foo that different major versions result if you do import "foo" and a corresponding require foo v2.2.2+incompatible, vs. import "foo/v3" and a corresponding require foo/v3 v3.0.0.

v2.0: Merge pull request #42 from zencoder/add-attributes

First stage adding additional parameters to match spec

v1.0

Removed 'suite' and moved to using 'require' instead of 'assert' (#43)