761311 - More sensible Sync version management

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Android Sync, defect)

Description

[Gregory Szorc [:gps]]

Currently, Firefox and Android Sync maintain their own version numbers and these version numbers are incremented by the Services team whenever a tree cuts over to a new Gecko version. Hopefully. I say hopefully because the Android Sync version bump for Firefox 15 didn't make it into the tree until a few hours before m-c was converted to 16!

We can do better.

At the very least, we should have the release managers perform this version bump as part of tree cutover. It is my understanding that this will happen automagically if we put the right content on https://wiki.mozilla.org/Release_Management/Merge_Documentation.

I'm not sure how Android Sync works, but Firefox Sync currently has its own x.y.z version scheme where y is incremented with each Gecko release. Unfortunately, y is currently at 18 and Gecko is at 16. In my ideal world, I think those versions align.

In a few months, "Sync 2.0" will land. At that point, we can probably go from 1.x.y to 2.x.y and set x to whatever Gecko version we're on. That's one solution.

An alternative is to pull in config/milestone.txt directly into Sync. This will get us the actual build information. e.g. "15.a1" This will give us more detailed usage info (yay). However, it /may/ break existing metrics/analytics.

I just think the status quo is silly and prone to failure. I could easily see us forgetting about this and having that bite us down the line when we try to debug client behavior.

I'm sure others will weigh in here...

Comment 1

[Richard Newman [:rnewman]]

(In reply to Gregory Szorc [:gps] from comment #0)

> I just think the status quo is silly and prone to failure. I could easily
> see us forgetting about this and having that bite us down the line when we
> try to debug client behavior.

+10000000000000000000.

Comment 2

[Gregory Szorc [:gps]]

I updated https://wiki.mozilla.org/Release_Management/Merge_Documentation#Version_Bumps to reflect what needs changed in services/sync/Makefile.in.

rnewman: can you add something on Android and close this bug out?

lsblakk: I figure you get final word.

Comment 3

[Richard Newman [:rnewman]]

I switched the Android Sync version number from 0.9 to 1.@MOZ_APP_VERSION@.0. That'll allow it to be auto-incrementing. In the standalone repo, MOZ_APP_VERSION is defined to be 0.

gps, review plz:

https://github.com/mozilla-services/android-sync/pull/235

The diff once this hits hg is simply:

diff --git a/mobile/android/base/sync/GlobalConstants.java.in b/mobile/android/base/sync/GlobalConstants.java.in
--- a/mobile/android/base/sync/GlobalConstants.java.in
+++ b/mobile/android/base/sync/GlobalConstants.java.in
@@ -5,15 +5,15 @@
 
 package org.mozilla.gecko.sync;
 
 /**
  * Preprocessed class for storing preprocessed values.
  */
 public class GlobalConstants {
   public static final String PRODUCT_NAME = "@MOZ_APP_DISPLAYNAME@";
-  public static final String SYNC_VERSION_STRING = "0.9";
+  public static final String SYNC_VERSION_STRING = "1.@MOZ_APP_VERSION@.0";
 
   public static final String USER_AGENT = "Firefox AndroidSync " + SYNC_VERSION_STRING +
                                           " (" + PRODUCT_NAME + ")";
   public static final String BROWSER_INTENT_PACKAGE = "@ANDROID_PACKAGE_NAME@";
   public static final String BROWSER_INTENT_CLASS = BROWSER_INTENT_PACKAGE + ".App";
 }

Comment 4

[Richard Newman [:rnewman]]

Greg reviewed in Git.

https://hg.mozilla.org/integration/mozilla-inbound/rev/75e0e7e61c9b

Henceforth:

  public static final String SYNC_VERSION_STRING = "1.17.0a1.0";

Comment 5

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/75e0e7e61c9b