Closed Bug 546695 Opened 14 years ago Closed 14 years ago

Update build scripts to support AUS schema 4

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: morgamic, Assigned: coop)

References

Details

The AUS schema will change for mobile updates.  Currently we have this schema:
/3/Firefox/3.5.8/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt

We'll be moving to something like:
/4/3.5.8/%GRE_VERSION%/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt

We'll discuss and add more details.
(In reply to comment #0)
> The AUS schema will change for mobile updates.  Currently we have this schema:
> /3/Firefox/3.5.8/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt
> 
> We'll be moving to something like:
> /4/3.5.8/%GRE_VERSION%/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt

Is there a reason why we wouldn't put the GRE_VERSION ahead of the version number to preserve the rest of the URL? 

e.g.:
/4/%GRE_VERSION%/3.5.8/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt

If we did this, is there any reason why we'd need to create a new /4 root dir? Could we not just add the new GRE_VERSIONs as products and use the existing /3?
(In reply to comment #1)
> (In reply to comment #0)
> > The AUS schema will change for mobile updates.  Currently we have this schema:
> > /3/Firefox/3.5.8/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt
> > 
> > We'll be moving to something like:
> > /4/3.5.8/%GRE_VERSION%/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt
> 
> Is there a reason why we wouldn't put the GRE_VERSION ahead of the version
> number to preserve the rest of the URL? 
> 
> e.g.:
> /4/%GRE_VERSION%/3.5.8/Darwin_Universal-gcc3/20100202152834/en-US/releasetest/partial.txt
> 
> If we did this, is there any reason why we'd need to create a new /4 root dir?
> Could we not just add the new GRE_VERSIONs as products and use the existing /3?

stuart/blassey/morgamic: at first glance, it seems like what we already have with "/3" should work fine for mobile updates. Can you elaborate why the change is needed?
I believe Morgamic meant /4/Firefox/3.5.8/%GRE_VERSION%/... which would create a new field.  This would be /4/Fennec/1.1/%GRE_VERSION%/ for fennec.
It was apparent that both would be needed in some cases.  We're changing the URL, we should change the filepath to reflect that change.  1/2/3 are all there to match their respective URL revisions.  How hard is this to do?  We can talk about it.
(In reply to comment #4)
> It was apparent that both would be needed in some cases.  We're changing the
> URL, we should change the filepath to reflect that change.  1/2/3 are all there
> to match their respective URL revisions.  How hard is this to do?  We can talk
> about it.

If we have to change the URL, that's fine. We'll update the build scripts if required.

From the releng POV, the underlying issue is mobile versioning. Instead of changing the version of the mobile product based on the mozilla branch it's building from, we're changing the URL format. If we sort out mobile versioning (which I assume would need to happen eventually anyway if you want to release a 1.5 or 2.0 version), mobile updates fit into the existing URL scheme.

Don't people get confused that the same version is applied to mobile builds coming from m-c vs. 1.9.2? I had to explicitly ask Aki the other day which branch the alphas were coming from before turning on the MAR generation because the versions are the same.

Note that whatever versioning scheme mobile chooses doesn't have to be set in stone. We've revisited previous version decisions in Firefox before (e.g. 3.1). It's not ideal, but can be done.
(In reply to comment #3)
> I believe Morgamic meant /4/Firefox/3.5.8/%GRE_VERSION%/... which would create
> a new field.  This would be /4/Fennec/1.1/%GRE_VERSION%/ for fennec.

If we're just adding the GRE_VERSION for all products, this makes much more sense to me. I withdraw my mobile versioning objections.
I need to confer with Nick about what all needs to change, but I'll be the one doing the work here.
Assignee: nobody → ccooper
Priority: -- → P3
Nick: when you've got a few minutes, can you comment on the code changes that need to happen on our side? I don't want to miss anything, and I confess that the AUS staging-to-production journey for snippets is still a little magical for me.
I'm assuming that AUS will also expect the snippet store to have the GRE_VERSION after the app version.  Looks like we'll have to
* add support for a milestone parameter to patcher-config-{bump,creator}, so that we can add that to each <release> block in the patcher config. Update the release automation for this
* add a parameter in the patcher config to control the snippet store layout, so that we have a transition story
* use the two new params in places like 
    http://mxr.mozilla.org/seamonkey/source/tools/patcher/patcher2.pl#1282

Are we moving Firefox over to version 4 URLs ? If so
* transition the existing 3/ snippet store to 4/ for the versions that need it
* make backupsnip & pushsnip support operating on 3/ or 4/ (we'll need this for fx3.0 and possibly tb2, even if we move Fx3.5 and later)

I would estimate there is several days of coding and testing here, particularly if we're touching updates for Firefox releases. I wasn't able to attend the meeting that kicked this bug off, so can you tell me why versioning mobile builds based on the gecko platform is undesirable ?
(In reply to comment #9)
> Are we moving Firefox over to version 4 URLs ?

I am not aware of any desire to move Firefox (Desktop) to version 4

> I wasn't able to attend the
> meeting that kicked this bug off, so can you tell me why versioning mobile
> builds based on the gecko platform is undesirable ?

mobile uses a separate Hg repo (mobile-browser) and does not branch to match mozilla-central / mozilla-192. Creating a mobile branch just so we can version based on gecko would seem to be a pain. We also do not wish to pull mozilla-central into the mobile-browser repo.

Therefore the simplest solution seems to be tracking Fennec with app version _and_ gecko version.
(In reply to comment #10)
> Therefore the simplest solution seems to be tracking Fennec with app version
> _and_ gecko version.

I *think* what Nick is suggesting here is using Fennec-%GRE_VERSION% as the product name so that it will fit into the existing version 3 schema and save everyone a lot of work. Is that tenable?
As I've said, that works for us. Although, the suggestion up til now has been %PRODUCT%/%VERSION%#%GRE_VERSION% (ex. Fennec/1.1#1.9.2)
I should have insisted the meeting be moved to a NZ-/nthomas-friendly time to avoid making the decision multiple times; sorry all.
(In reply to comment #12)
> As I've said, that works for us. Although, the suggestion up til now has been
> %PRODUCT%/%VERSION%#%GRE_VERSION% (ex. Fennec/1.1#1.9.2)

Agree with Brad. Either of these work for us. Both would avoid the version 4 scheme.

Although, would using a hash "#" in the middle of a URL be legal? Those are usually for anchors, right?
From some offline discussions, blassey: mfinkle aki nthomas coop joduinn now all believe we can do WinMO updates using v3 schema (with some open debate about %VERSION%#%GRE_VERSION%  vs %VERSION%-%GRE_VERSION% vs %VERSION%_%GRE_VERSION%)

This would mean no v4 script changes needed, so am closing as WONTFIX. 

Morgamic: if you *require* a v4 for some reason that we are missing, please reopen.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
That'll work as long as it's in the correct place in the incoming URL.
Metrics just discovered today that we have been skipping AUS request data from Fennec on the nightly channel because it is using a version 4 schema that looks similar to what is discussed in this bug (the original part where %GRE_VERSION% appears as a new path component after the product version.

Is there another bug that reflects the fact this change actually made it into the codebase?  How long have we been dropping the data on the floor because we didn't know about the new schema?
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.