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 _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
