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

[Petr Mladek]

Hi Rainer,

let me to move the dicussion to the mail. We need an operative solution
and I think that a mail is better for it.

On Wed, 2012-06-06 at 18:01 +0200, Rainer Bielefeld wrote:
> Hi,
> 
> Houston, we have had a problem :-(
> 
> Can you please have a look at my Problem in 
> <https://wiki.documentfoundation.org/Talk:BugReport_Details#Concern_2>?

> Concern 2 
> 1. Independent to all we have the problem that in the query mode   
>    Bugzilla shows the versions in order of creation. That's bad, but I
>    can't change it. But may be I should do the rename action in a good
>    sort order? No idea what the result will be, may be the sort order
>    in the query Version picker will be messed up terribly.

I have no experience here. We need to rely on your test results or we
need to find a bugzilla expert.

> 2. The Idea was to use the Help/about contents (like 3.6.0beta1) as
>    Version info and add Info like "RC" or "release" after a blank. And
>    I hope that the sort order in the Bug view (for existing Bugs),
>    what is alphabetical, should be the correct historical order (at
>    least in most cases). But checking my 3.8 test versions (I will
>    delete them after tests will have been finished) unfortunately
>    shows that the historical sort order will be broken. The problem is
>    not the blank, but the missing tailing ".x" in the alpha and beta
>    versions.

Hmm, we have similar problem in versioning rpm packages. They compare
the version alphabetically as well.

> Additional Ideas 
> 
> We could write the version numbers in Help/About as 3.9.0.0beta1
> instead of 3.9.0beta1. That would heal the sort order as you see in
> my 3.8.0.0beta0. But this trick will (of course) not work for already
> existing versions, and would be a change in the Version numbering /
>  release engineering. Is it that worth?

We use slightly different version scheme for source tarballs and rpm
packages:

+ 3.X.98.Z for Zth alpha of 3.(X+1) release,
  for example 3.5.98.1 for 3.6.0-alpha1
+ 3.X.99.Z for Zth beta of 3.(X+1) release,
  for example 3.5.99.1 for 3.6.0-beta1
+ 3.X.0.Z for Zth rc of 3.X.0 release,
  for example 3.6.0.1 for 3.6.0-rc1
+ 3.X.Y.Z for Zth rc of Yth 3.X bugfix release,
  for example 3.6.1.1 for 3.6.1-rc1
   
We could add this version into the about dialog as well, for example:

   version 3.5.99.1 (3.6.0 beta1, buildid: 432fw2)

Well, it looks a bit ugly. In addition, we can't mention "rc" because it
must not appear in the final build. So, it would look for RC as:

   version 3.6.0.1 (buildid: fddfg23)

On the other hand, I prefer it over 3.6.0.0 because 3.6.0.0 source
tarball will newer exist; Also the 3.X.98.Z and 3.X.99.Z is
corresponding with the source tarballs and git tags.

I just was not brave enough to put 3.X.98 into about dialog. I was
afraid that it might confuse users. But we might explain it in the
brackets. 

Could we use the same scheme also in bugzilla? I mean:

   3.5.98.1 (3.6.0alpha1)
   3.5.98.1+ (3.6.0alpha1+daily)
   3.5.99.1 (3.6.0beta1)
   3.6.0.1 (3.6.0rc1)
   ...

I think that we do not need to care that much about 3.4 and 3.5 betas;
they are dead anyway. I still could put the new version scheme into
about dialog for the upcomming 3.6.0betas.


Best Regards,
Petr