[meta] Make the version field uniform across products
Categories
(bugzilla.mozilla.org :: Administration, task, P3)
Tracking
()
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.
|
Assignee | |
Comment 1•5 years ago
|
||
This will require tools from RelEng to update to use a single, consistent format as well.
|
|
Assignee | |
Comment 2•5 years ago
|
||
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.
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 3•5 years ago
|
||
Are we going to replace the Version and Target Milestone fields with status flags?
|
Reporter | |
Comment 4•5 years ago
|
||
This is a different discussion. I would prefer to focus first on fixing this issue as it doesn't require much coordination.
|
|
Assignee | |
Comment 5•4 years ago
|
||
There's a request to do this for Web Extensions in bug 1568346.
|
|
Assignee | |
Comment 6•4 years ago
|
||
:dkl, what would be the side effects (aside from 3rd party tool dependencies) on making all the milestones and versions consistent across Firefox products?
|
||
Comment 7•4 years ago
|
||
(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
|
|
Assignee | |
Comment 8•4 years ago
|
||
Yes, I think that's a perfect use of tracking flags.
|
|
Assignee | |
Comment 9•4 years ago
|
||
Considering for 1H20
|
|
Assignee | |
Comment 10•4 years ago
|
||
|
|
Assignee | |
Comment 11•4 years ago
|
||
Now filing dependencies.
|
|
Assignee | |
Comment 12•4 years ago
|
||
Components will be able to opt-into using values of cf_status_firefoxNN as a source of truth for Version and Milestone.
|
|
Assignee | |
Comment 13•4 years ago
|
||
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.
|
|
Assignee | |
Comment 14•4 years ago
•
|
||
Question: is it better to retroactively apply the new values to earlier releases, or just start with the new values.
|
|
Assignee | |
Comment 15•3 years ago
|
||
New values are active now.
Description
•