[Libreoffice-qa] New Bugzilla Version Picker items – 2

Petr Mladek pmladek at suse.cz
Thu Jun 14 00:34:40 PDT 2012

Hi Rainer,

sigh, I missed this mail because I was not in CC... :-(

On Sat, 2012-06-09 at 10:35 +0200, Rainer Bielefeld wrote:
> Bjoern Michaelsen schrieb:
> > 3.X.Y_alphaZ   - for alpha releases
> > 3.X.Y_betaZ    - for beta releases
> > 3.X.Y.Z       - for release candidates
> Hi Bjoern,
> I think we should only use 1 kind of separator, everything else produces 
> impredictable sort order results in different contexts.
> Unfortunately replacing th underscore by a dot does not heal Bugzilla 
> sort order problems, here an example I see in Bugzilla:
> rc 	
> rc 	
> release 	
> 3.8.0.beta1 	
> 3.8.0beta1 	
> 3.8.0beta2 	
> 3.8.0_beta1
> That's ugly	

Grrrr, I am confused. This is not alphabetical sorting. It seems that
bugzilla seems to be somehow clever.

I guess that this non-alphabetical sorting is by purpose. It has the
advantage that "beta" suffixes are displayed after "rc" and "pure
number" versions. Betas are are obsolete the by final releases. It is
good to have "RCs" and final releases on top.

I wonder if there is a global setting that could disable this strange
feature in bugzilla.

> Condensing this my suggestion for releases is some structure like

> MajorVersion.Version.MicroVersion.Workflow.PreReleaseInfo
> (rc info not in Help about) 	
> (rc info not in Help about) 	
> (release info not in Help about)  	

This might be a good compromise if we can't disable the strange bugzilla
sorting and can't live with it. 

> Any Idea how we can integrate the Branch and Master Versions? Please 
> keep in Mind that I do not want to have them all in the Version picker, 
> that would produce an endless slider for Versions with 1 reported Bug or so.

I am confused. What do you mean by branch and master versions?

IMHO, it would make sense to remove "alpha" and "beta" versions from
bugzilla few months after the release. If we do not know exactly that a
bug appeared in the given "beta", we do not need this granularity. IMHO,
we get better information from the bibisect.

> BTW I am not happy with the current
> "libreoffice- tag created (3.6.0-beta1)"
> Although this approach has the charm of "mathematical correctness", we 
> can't do that without a volunteer answering all questions like "I have a 
> 3.6.0 with a 3.5 Tag number, is that a bug?" ;-)
> I believe that's too worrying for users (although it seems to work for 
> Mozilla, but do we have info how happy they are with that?). But of 
> course, that's only my private feeling.

I think that is not that bad. On the other hand, I agree that,, is a better solution.

Best Regards,

More information about the Libreoffice-qa mailing list