Closed Bug 589489 Opened 11 years ago Closed 11 years ago

Ensure usage of a versioning format in which new features are not released in minor (patch-level) updates

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: haqer, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

Lorentz was released as 3.6.4 and became a precedent for expected future releases following the same practice of releasing non-minor features as a minor/patch update.
This leads to semantic ambiguity of what a minor update is, prevents proper discussion and resolution of privacy-related bugs, and in general is just plain confusing (in terms of when to expect new features and UI changes, etc.).

I'm using the following versioning nomenclature below:
super.major.minor
or
super.major.inter.minor
(assuming that 
major[.minor[.release[.build]]][+]
nomenclature is deprecated, but corresponding to it, though w/ "major" mapping to a different part semantically).

Reproducible: Always

Steps to Reproduce:
1. Imagine a future release like Lorentz, referred to as "Wonderful" below.
2. Check the versioning of said release
Actual Results:  
As of now, "Wonderful", preceded by 4.0.3, will be released as 4.0.4.

Expected Results:  
"Wonderful" should not be a minor, or patch-level release, and should be released as one of the following releases, or something to the same effect:
a. "Wonderful" is preceded by 4.0.0.3, and is released as 4.0.1 (or 4.0.1.0, where 1 is "inter" (in-between major and minor) version, and optional 0 is minor version). Here, a future major release, "Awesome", would be released as 4.1, or 5.0. In this approach, "Wonderful" is released from the same branch as 4.0.0.3, and a minor update to it (on that branch) would be released as 4.0.1.1, and there would be no 4.0.0.4 release. (Alternatively,  "Wonderful" could be on its own branch, followed by 4.0.0.4 and 4.0.1.1 releases from different branches).
b. "Wonderful" is preceded by 4.0.3, and is released as 4.1. No versioning change in comparison to 3.6 and Lorentz, but a policy change of not releasing new features, even w/ small UI changes, as a minor update or patch-level release.

There is a scheduled User-Agent format change for Firefox 4. Ideally, there would be either an enhanced versioning format, or an adoption of a policy of not releasing new features in non-minor updates before this User-Agent format is frozen.
Summary: Ensure usage of a versioning format in which non-minor features are not released in minor/patch-level updates → Ensure usage of a versioning format in which new features are not released in minor (patch-level) updates
Version: unspecified → Trunk
This is better taken to the mozilla.dev.planning newsgroup.  It's definitely not the right product/component, and this is not a good forum for this kind of discussion.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
(In reply to comment #0)
> There is a scheduled User-Agent format change for Firefox 4. Ideally, there
> would be either an enhanced versioning format, or an adoption of a policy of
> not releasing new features in non-minor updates before this User-Agent format
> is frozen.
Of course i meant:
... or an adoption of a policy of
not releasing new features in _minor_ updates before this User-Agent format
is frozen.
(In reply to comment #1)
> This is better taken to the mozilla.dev.planning newsgroup.  It's definitely
> not the right product/component, and this is not a good forum for this kind of
> discussion.
I disagree with Josh's closing of this bug w/o any discussion. 
Now is the time to discuss this given UA string format change happening for Firefox 4.
This also affects discussions of bugs like bug 572659, where if Lorentz was preceded by 3.6.0.3, and was released as 3.6.1, people could approach the dropping of minor version from UA string differently.
That said, I'm leaving it up to others to revert Josh's "RESOLVING", and/or otherwise contribute to this discussion...
Component: Networking: HTTP → General
I realize my use of "this" may have been a bit unclear.  I've got nothing against the proposed discussion; I just don't believe that bugzilla is the right place for it to occur.  The aforementioned newsgroup is a much more appropriate forum.
(In reply to comment #4)
One of the approaches involves potential (hopefully avoidable) User-Agent format change, and the discussion relates to currently actively worked on bugs, related to the upcoming Firefox 4 release. Therefore, i think this bug is an appropriate and better place for this discussion; w/ the added little advantage of referring to other bugs and comments w/o having to paste the full urls.
Plus, this issue has to be really RESOLVED by appropriately privileged people:
i. either enhanced versioning,
ii. adopted policy commitment or 
iii. WONTFIX.
A forum discussion doesn't lend itself to any kind of formal resolution, therefore it's not appropriate. True resolution of this bug would also surface in bugzilla searches later on, avoiding possible duplicates and informing other related decisions.
Notice the following untranslated string in French locale:
Some of the trademarks used under license from The Charlton Company.

This has been logged as bug 595567, but i'm attaching the screenshot here because the root cause is the dubious project management approach of releasing new non-minor features as minor releases.
This of course is a minor issue, but it affected all non-English users of an application adopted by 25% of Internet users. And of course, had 3.6.4 been treated as a non-minor release like it should, this issue would have been resolved before the OOPP feature was released. 
IMHO, project management literature could mention this as an example of sloppy release management (versioning).
I think mozilla deserves a release versioning approach that would prevent such issues in the future (which could of course end up being more serious than just an untranslated string).
You need to log in before you can comment on or make changes to this bug.