229849 - Naming convention for firebird nightlies in UAs

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[alanjstr]

Right now both trunk and 0.8 branch say Firebird 0.7+
I think that Firebird should move to a naming convention more like Seamonkey.
The 0.8 branch would become 0.8b until it is finalized.  The trunk will continue
as 0.9a

Comment 1

[MORA]

I agree, the current naming convention is confusing. Apparantly, I am not the
only one, judging from the the many version numbering threads in the MozillaZine
forums.

Perhaps the trunk builds shouldn't have a version number at all? I think
something like:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031231
Firebird/trunk

would imho be a quite workable alternative.

Comment 2

[Mike Coppins]

As rather a lot of Firebird users prefer to go for "the bleeding edge", and more
of a balance is needed between the release line and trunk line, I think "stable"
and "unstable" would be a better choice.

Comment 3

[Mike Coppins]

(wrt "more of a balance" I meant "balance of number of users")

Comment 4

[alanjstr]

trunk, stable, and unstable don't really indicate the version of Firebird. 
There is no guarantee that Firebird will always be in sync with Seamonkey
releases.  The naming convention of SM seems to be pretty well ingrained.

Comment 5

[Michael Lefevre]

I don't think there's anything wrong with Firebird's current conventions, as I
understand them.  The current confusion arises from the fact that the trunk
version number hasn't been changed - logically, it should have been bumped to
0.8+ after the branch.

Comment 6

[Brian Earley]

The naming convention could also use a build date instead, the date changing for
every nightly.

For example:--
For a milestone:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

For trunk nightlies:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Firebird/20040106

Gecko's build date is not the same as the date of the build, is it? If not, this
would work.

Comment 7

[alanjstr]

Yes, that date reporesents when it was built.  

Comment 8

[Will Rickards]

[quote]
I think that Firebird should move to a naming convention more like Seamonkey.
The 0.8 branch would become 0.8b until it is finalized.  The trunk will continue
as 0.9a[/quote]

Yes this would make it so much clearer!
This seems much clearer to me being new to firebird.
You've all probably seen the number of mozillazine posts that say, 'bug: version
number was not incremented'.  And you've all seen the posts from people trying
to figure out the build by the date in the UA string.  Sometimes it isn't
correct even though it is a newer build?

Comment 9

[Mike Connor [:mconnor]]

the 0.8 release will be 0.8, so I don't see why there is any reason to block the
release for changing the convention.

Comment 10

[Wolf [:wolf]]

Since Firebird doesn't really have a beta period.. it'd make sense for it to be
0.9a (for trunk) till the release.. and not 0.8+... Since it's basically Alpha
then Release (Milestone).. as it'd be a quick indication of what part of the
trunk/branch the release came from. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040204
Firebird/0.9a 

would make the most sense... as long as the Gecko date actually represents the
specific date of the nightly... then the Firebird rv makes it quick to determine
trunk vs. branch vs. release.. (unlike 0.7+/0.8+ which just make you think it's
continuing the same branch, beyond the release.. )

Comment 11

[Grey Nicholson (they/them)]

Yes. We should have Firebird/0.9a for the trunk. Then, when it branches, the
branch should become Firebird/0.9b and the trunk Firebird/0.10a.

Comment 12

[Mike Connor [:mconnor]]

Okay, this isn't about naming conventions for milestones.  Those are 
established (like 0.8, and if there was a point release it'd be 0.8.1, just 
like the 0.7.1 point release)

This really just addresses the UA shown in nightlies, which means very very 
little at this point, other than for testers, who should know what the scheme 
means, and if they don't they should just learn it.

Comment 13

[Thomas]

If I continue with comment #12, then this is a "wontfix"?

Comment 14

[alanjstr]

I'd like to leave this open until after Firefox 1.0 and see where the direction
of Mozilla 2.x goes.

Comment 15

[Mike Connor [:mconnor]]

The versioning that's in place is what we're going with.  The extension manager
was designed around this versioning scheme, and doesn't recognize alpha/beta
text.  There doesn't appear to be any real reason to break EM to change the
versioning scheme in nightlies.  Maybe a doc on the projects page to explain the
versioning scheme for nightlies would be useful, but that's about it.