Difference between branches 2214 and 2214_85

[Aline]

Hi,

I‘m following Chromium stable releases on Linux and I’m working with the version tagged 40.0.2214.95. Using gitk, I noticed that this version was tagged on branch 2214_85 and not on branch 2214 (see the attached screenshot). I didn’t find any explanation about this divergence. Could you please help me understand why there are these two branches?

Thanks&Regards,

Aline

[Daniel Bratell]

On Tue, 24 Feb 2015 14:03:51 +0100, Aline <api...@cisco.com> wrote:

Hi,

I‘m following Chromium stable releases on Linux and I’m working with the version tagged 40.0.2214.95. Using gitk, I noticed that this version was tagged on branch 2214_85 and not on branch 2214 (see the attached screenshot). I didn’t find any explanation about this divergence. Could you please help me understand why there are these two branches?

(Note: I'm at Opera so I've only studied this from the outside; we were also a bit confused at the start)

At points in the release process different google chrome products may diverge and when that happens they allocate a sequence of version numbers (the very last number) for that diverging product and make a side branch, in this case 2214_84, extracted from 40.0.2214.84 and used for a couple of versions after that.

This can make it a bit interesting where 20.0.34.50 might lack changes that are in 20.0.34.49.

I think there used to be more branch information at http://omahaproxy.appspot.com/ but now it just says "master" everywhere.

/Daniel

[Paweł Hajdan, Jr.]

+infra-dev,mmoss

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Michael Moss]

Nothing to do with infra. These numbering scenarios are completely managed by the release managers, and Daniel's explanation was fine. Basically, sometimes they make a branch of a branch (a.k.a. a mini-branch), which causes release numbers to seemingly jump around, if you look at them chronologically. It's fairly rare, and the mini-branches usually only live for a release or two, but it does happen.

[Shezan Baig]

As a follow up, do you know why https://omahaproxy.appspot.com/viewer now just shows "master" in the "true_branch" field?

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Aline]

Thanks for your responses.

What you said was clear and I understand but I would like to know the reason why the “mini-branch” was created in this particular case.

[Michael Moss]

On Tue, Feb 24, 2015 at 9:05 AM, Shezan Baig <shezb...@gmail.com> wrote:

As a follow up, do you know why https://omahaproxy.appspot.com/viewer now just shows "master" in the "true_branch" field?

It looks like the current releases do all branch from master. When .95 was current, did it still show master as the true_branch?

 

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CANMpiOT7OAFw%2B-VxrquHYycY50rzUxV-RkcARZMTrhqi4qN16A%40mail.gmail.com.

[Anthony LaForge]

I believe that that particular case may have had to do w/ a Flash Player update.  The purpose of a mini_branch is to take a snapshot from a known, quantifiable release, and then (using that as the base) take a very narrow set of patches (e.g. a Flash update) to address some specific issue.

Since merges happen on the branch, post release, we need to carefully evaluate the risk of releasing from the tip of the branch versus creating a mini_branch w/ a minimized patch set.   All things being equal, our strong preference is to do releases from the primary branch.

For the most part, for downstream projects, I'd recommend tracking the primary branch.  There would never be (or rather I cannot imagine) a scenario where we would only patch a mini_branch and not the primary branch as well, since the goal is always to get back to releasing on the primary branch.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

[Shezan Baig]

On Wed, Feb 25, 2015 at 3:49 PM Michael Moss <mm...@chromium.org> wrote:

On Tue, Feb 24, 2015 at 9:05 AM, Shezan Baig <shezb...@gmail.com> wrote:

As a follow up, do you know why https://omahaproxy.appspot.com/viewer now just shows "master" in the "true_branch" field?

It looks like the current releases do all branch from master. When .95 was current, did it still show master as the true_branch?

I don't recall, but I believe before the git switch, the "true_branch" would display the 3rd number from the version tag (e.g.  true_branch for "40.0.2214.115" would be "2214").

It's not a big deal, I was just curious :)

[Shezan Baig]

Actually, I have historical records.  When 40.0.2214.94 was current, it did show "2214" for true_branch.  But when 40.0.2214.111 became current, it started showing "master".

I don't think there was ever a 40.0.2214.95 (at least not for win/stable, which is all I have records for).