Closed Bug 1553533 (status-version-milestone) Opened 4 years ago Closed 2 years ago

[meta] Make the version field uniform across products

Categories

(bugzilla.mozilla.org :: Administration, task, P3)

Production

Tracking

()

RESOLVED FIXED

People

(Reporter: Sylvestre, Assigned: emceeaich)

References

()

Details

(Keywords: bmo-goal)

In core, DevTools and Firefox: we have 68 branch, 69 branch, etc.
See:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core

In Firefox for Android, we have Firefox 68, Firefox 69, etc.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox%20for%20Android

Maybe it made sense at some point in the history but it doesn't anymore.

We should move to a single definition.

This will require tools from RelEng to update to use a single, consistent format as well.

See Also: → 1404530

I've closed bug 1404530.

Since I'm proposing a target/planned version field as a program flag, maybe move milestone to a program flag.

Summary: Uniform the version field → Make the version field uniform across products

Are we going to replace the Version and Target Milestone fields with status flags?

This is a different discussion. I would prefer to focus first on fixing this issue as it doesn't require much coordination.

:dkl, what would be the side effects (aside from 3rd party tool dependencies) on making all the milestones and versions consistent across Firefox products?

Flags: needinfo?(dkl)

(In reply to Emma Humphries, Bugmaster β˜•οΈπŸŽΈπŸ§žβ€β™€οΈβœ¨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #6)

:dkl, what would be the side effects (aside from 3rd party tool dependencies) on making all the milestones and versions consistent across Firefox products?

Well aside from BMO not supporting this type of association and would take a lot of work to make it do that, that would be one side effect :) I would suggest that we would use tracking flags that has the versions and milestones and enable them for the Firefox products. That is something that could be done without any code change. But then we would need to create a script to migrate the current versions/milestones over to the new tracking flags and then remove the old version/milestone value. Does that sound like something worth looking into?

dkl

Flags: needinfo?(dkl) → needinfo?(ehumphries)

Yes, I think that's a perfect use of tracking flags.

Flags: needinfo?(ehumphries)

Considering for 1H20

Assignee: nobody → ehumphries
Priority: -- → P3

Now filing dependencies.

Alias: status-version-milestone
Summary: Make the version field uniform across products → [meta] Make the version field uniform across products

Components will be able to opt-into using values of cf_status_firefoxNN as a source of truth for Version and Milestone.

We're doing a simplified version of this where we unify the version and milestone field values starting with Firefox 81 (see https://docs.google.com/document/d/1DkEu8CarVVzKzO_tEmazGjsb3vmbkCvLKhEQmSvAzAU/) (Note, this doc is internal-only for the moment, but after review we'll open it to the public.)

This removes the dependencies we have on changing Bugzilla code and relies on configuration.

Waiting for feedback on the plan to determine if we should retroactively update the version and milestone fields across the Firefox-related projects, or just use the new scheme starting with Firefox 81.

Question: is it better to retroactively apply the new values to earlier releases, or just start with the new values.

Status: NEW → ASSIGNED

New values are active now.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Regressions: 1685952
Depends on: 1799774
You need to log in before you can comment on or make changes to this bug.