1074395 - request to change versioning of future openh264 plugins

Status: RESOLVED FIXED

(Core :: Audio/Video: GMP, defect)

Description

[[e-mail] (:bhearsum)]

While working on bug 1013354 I realized that the current the OpenH264 plugins are versioned is a bit of pain, and not entirely accurate. As far as I can tell, we currently version them in two ways:
* The plugin version itself
* An associated Firefox (Gecko, really) version.

Right now we have two plugins we're serving, and we call the files things like:
http://ciscobinary.openh264.org/openh264-macosx64-v1.1-Firefox33.zip
http://ciscobinary.openh264.org/openh264-macosx32-v1.1-Firefox34.zip

The confusing part about this is that Firefox34 plugin is actually not just for Firefox 34 - it's for 34 and higher (until the next time we make a change that requires a new Gecko version). For anyone looking at the data on the update server, this means that they need to 

I think we can do better by sticking to a single version, with two parts. First part will rev whenever we break compat with gecko. The second part will change when there's a change that doesn't break compat. If we used this for the current state of things, this would mean:
* We have plugin version 1.0, being served to Firefox 33
* We have plugin version 2.0, being served to Firefox 34
* The next non-compat change would have us build 1.1 and 2.1.
* The next compat breaking change would have us 3.0

If people don't like bumping the "major" version, we could prepend "1." to everything above and only bump that when people feel like it.

Comment 1

[Ethan Hugg [:ehugg]]

The "v1.1-Firefox34" in that name refers to the branch of OpenH264 repo.

Before this latest build of OpenH264 the files included the commit ID and were named things like this:

openh264-linux32-master-300cceaabf0c423a3f464c963ac1b7abdae6e6b3.zip
openh264-linux32-v1.1-Firefox33-b4504d4da483d83246633f7ad03b9f60400abaf6.zip

Not that that's better, but it does maintain uniqueness which is important for adding to the CDN.

That said,  a new version scheme would be fine as long as it handles point releases.

Comment 2

[[e-mail] (:bhearsum)]

(In reply to Ethan Hugg [:ehugg] from comment #1)
> The "v1.1-Firefox34" in that name refers to the branch of OpenH264 repo.
> 
> Before this latest build of OpenH264 the files included the commit ID and
> were named things like this:
> 
> openh264-linux32-master-300cceaabf0c423a3f464c963ac1b7abdae6e6b3.zip
> openh264-linux32-v1.1-Firefox33-b4504d4da483d83246633f7ad03b9f60400abaf6.zip
> 
> Not that that's better, but it does maintain uniqueness which is important
> for adding to the CDN.

This versioning scheme should do it, too. Anytime we build a new version, the version would bump. So we'd have filenames like openh264-linux32-1.1.zip and openh264-linux32-2.1.zip (we wouldn't need to include the git branch in the url anymore - and I'd suggest it would be best not to because they often include version version numbers).

> 
> That said,  a new version scheme would be fine as long as it handles point
> releases.

I think my proposal above does, assuming point release is the same as non-compat breaking change - any point release would bump the last section of the version number.

Comment 3

[[e-mail] (:bhearsum)]

Ethan, it sounds like you're fine with this based on my reread of everything...can we go ahead and agree to use the new version numbering in newly created branches?

Comment 4

[Ethan Hugg [:ehugg]]

Yes that's fine.  I will double-check with you before versioning next time we build.  I don't have a build planned so it may be a while.

Comment 5

[[e-mail] (:bhearsum)]

Thanks Ethan!

catlee, callek - needinfo'ing you just to make sure you see this, since you two usually do the builds.

Comment 6

[Justin Wood (:Callek)]

I've usually deferred to catlee on what to call them, but I can consider myself informed now. Thanks.

Comment 7

[Chris AtLee [:catlee]]

Sounds fine to me. We should edit the build script to package this up correctly.