328497 - AUS Entries for new product versions?

Status: RESOLVED FIXED

(AUS Graveyard :: Administration, task)

Description

[Scott MacGregor]

Mike, apologies if I'm making a bad assumption here. I've finally learned how to make my Thunderbird 1.5.0.2 tinderbox machines start generating partial patches. But my knowledge about how that interacts with AUS is very poor.

When I ping AUS, it's not giving me back an XML file with the update information for this 1.5.0.2 partial patch.

Do I need to somehow inform AUS of new product versions like 1.5.0.2?

Here's the AUS URL that would correspond to the first set of partial patches I generated this morning:

https://aus2.mozilla.org/update/1/Thunderbird/1.5.0.2/2006022314/WINNT_x86-msvc/en-US/nightly/update.xml

If we do need to inform AUS of new versions, then an additional heads up that I plan on renaming the Thunderbird 1.8 branch builds from 1.5 to 2.0a1 so requests will look like

aus2.mozilla.org/update/1/Thunderbird/2.0a1/....

The trunk is getting renamed from 1.6a1 to 3.0a1

Comment 1

[Michael Morgan [:morgamic]]

The local AUS scripts that take the build data and create the XML files need to map incoming requests to their source directories.

In the config.php file located in /opt/aus2/app/inc/config.php, there is an array that accomplishes this mapping.

This array, $branchVersions, is defined as:
---
// This hash defines the version->patch relationships.
// It determines which patches are associated to which incoming client versions.
// @todo replace this with a better datasource that can be easily managed via a GUI.
$branchVersions = array(
    '1.0+' => '1.5',
    '1.4'  => '1.5',
    '1.4.1'=> '1.5',
    '1.5'  => '1.5',
    '1.5.0.1' => '1.5.0.1',
    '1.6a1'=> 'trunk'
);
---

Since client versions don't have a one-to-one relationship between their version string and the source directory, this array was created to add more flexibility.

Unfortunately, it needs to be kept up to date when versions are incremented.

Does this help clear things up?

Comment 2

[Michael Morgan [:morgamic]]

BTW, I added the 1.5.0.2 -> 1.5.0.2 mapping.  We might need to discuss the other changes.

Comment 3

[Scott MacGregor]

Thanks Mike, I just verified that partial updates are getting found for 1.5.0.2! Thanks for the explanation and for adding the entry.

I will hold off on checking in the version changes for the trunk and the 1.8 branch since it sounds like you want to talk about that. 

Comment 4

[Michael Morgan [:morgamic]]

Since you're here we could do it now...

What we really need to just figure out is:
[incoming version] => [branch source directory]

So, in our case here, we want to add:
3.0a1 => trunk
2.0a1 => 1.5

Is that right?

Comment 5

[Scott MacGregor]

(In reply to comment #4)
> Since you're here we could do it now...
> 
> What we really need to just figure out is:
> [incoming version] => [branch source directory]
> 
> So, in our case here, we want to add:
> 3.0a1 => trunk
> 2.0a1 => 1.5
> 
> Is that right?
> 

That's correct Mike. Although this means we'll come bother you again for 2.0a2, 2.0b1, 2.0b2 and 2.0 final for additional entries. 

cc'ing bsmedberg in case I'm saying something incorrect about the version mappings for the 1.8 branch. He has a good sanity checker.

Comment 6

[Benjamin Smedberg]

That sounds correct, though I'm not quite sure what "1.5" means in this case (the update channel? Should this be "2.0" starting now?). You might as well add the 2.0b1, 2.0b2 and 2.0 mappings now.

Comment 7

[Michael Morgan [:morgamic]]

The build snippets get stored in directories relating to their branch, so for in Thunderbird's case I see:

drwxr-xr-x  5 cltbld cltbld 4096 Sep  2 18:17 1.5
drwxr-xr-x  4 cltbld cltbld 4096 Feb 23 17:10 1.5.0.2
drwxr-xr-x  5 cltbld cltbld 4096 Sep  2 18:18 trunk

Per our discussion, we are adding:
2.0b1
2.0b2
2.0

That means we need to map these to a branch directory that doesn't exist yet.  Will the build systems write the correct snippet data to a directory named "2.0"?

Will our mappings then be:
2.0b1 => 2.0
2.0b2 => 2.0
2.0   => 2.0

Comment 8

[Benjamin Smedberg]

Where do the build systems write this information, and where does it come from?

Comment 9

[Michael Morgan [:morgamic]]

Build systems write it to a server that then gets synced with LVS.  The data comes from the build systems as they spin off builds as a part of the build script.  Paul is more familiar with these scripts than I am.

Comment 10

[Scott MacGregor]

Mike, I'm willing to be the guinea pig on this. It might take us a few days of builds to work it out.

Let's map 2.0a1, 2.0a2, 2.0b1, 2.0b2 and 2.0 to "2.0".

I think I see the build variable I can tweak to make this work but won't know for sure until we try it. I think we just need to change the update_version variable in tinder-config.pl. Leaving appv and extv alone. I can pass this knowledge on to the Firefox build folks once we know that it works. :)

Sound like a plan?

Comment 11

[Michael Morgan [:morgamic]]

(In reply to comment #10)
> Let's map 2.0a1, 2.0a2, 2.0b1, 2.0b2 and 2.0 to "2.0".
> 
> Sound like a plan?
Sounds good - I put in the mappings for 2.0a1,a2,b1,b2,etc. => 2.0.  Should be up in < 10 min.

Let me know if there's something else I can do to help.

Comment 12

[Scott MacGregor]

Mike, can you add just one entry for 3.0a1 --> trunk as well? I don't think we need b1, b2 and final entries yet since that's so far away.

Comment 13

[Michael Morgan [:morgamic]]

Sure.  Added 3.0a1 => trunk.

Comment 14

[Scott MacGregor]

Ok I tried this out on the 1.8 branch with Thunderbird. 

There is a downside to changing the AUS directory to 2.0 from 1.5:

The automated build system won't generate a partial patch from 1.5 to 2.0 for the nightly builds. So a user is going to have to download a 2.0a1 nightly installer build to get going again with automated nightly builds. This could be a big pain to  nightly testers. 

We can revert the value back to "1.5" in the AUS array and in the build config if we think making nightly testers re-download a full build before they can get back into software update again. 

Keep in mind end users never see this 1.5 string, it's just a communication mapping between the build system and AUS.

Thoughts on the right thing to do? Leave it at 2.0 or revert it back to 1.5?

Comment 15

[Scott MacGregor]

changing the app version to 2.0a1 seems to have broken extension compatibility for extensions that are configured to work for 1.5 to 1.5.0.*. 

For some reason, I was naively thinking if I left update_extv alone at 1.5 that extensions would still think they were compatible with 2.0a1. 

Benjamin do you know if it is our intention to require extensions to change their app compatibility strings to range from 1.5 to 2.0 even though internally we are trying to not break extensions going from 1.5 to 2.0?

Comment 16

[Benjamin Smedberg]

We are not trying to keep compatibility with most extension for 2.0, and we are requiring them to revalidate. Many extensions that deal with bookmarks and history will be broken, of course, but also extensions that overlay the urlbar, searchbar, or other chrome will need to be updated.