Hello Mike,
On 3/4/23 13:45, Xisco Fauli wrote:
Hello,
On 1/4/23 16:00, Mike Kaganski wrote:
On 01.04.2023 16:45, Mike Kaganski wrote:
2. I believe we can just have *major* releases, without point
releases. I.e., 3.3.0.4; 3.4.0.1; 3.5.0.3; 3.6.0.4; 4.0.0.0.beta1; ...
Because when we bibisec
Hello,
On 1/4/23 16:00, Mike Kaganski wrote:
On 01.04.2023 16:45, Mike Kaganski wrote:
2. I believe we can just have *major* releases, without point
releases. I.e., 3.3.0.4; 3.4.0.1; 3.5.0.3; 3.6.0.4; 4.0.0.0.beta1; ...
Because when we bibisect, we do it to do the following bisection in
the
Hello,
On 3/4/23 9:11, Mike Kaganski wrote:
Why? What is the upside of having them
The upside is that it's easier to identify when a regression was introduced.
If the repo just has one release closest to the branch point, then there
are thousands of commits between each release. However, if
On 03.04.2023 9:55, Xisco Fauli wrote:
2. I believe we can just have *major* releases, without point
releases. I.e., 3.3.0.4; 3.4.0.1; 3.5.0.3; 3.6.0.4; 4.0.0.0.beta1; ...
Because when we bibisect, we do it to do the following bisection in
the specific repo; so the branch point is the only int
Hello,
On 1/4/23 15:45, Mike Kaganski wrote:
Hi!
On 31.03.2023 20:50, Xisco Fauli wrote:
I recreated the bisect repository from scratch and reuploaded it to
https://bibisect.libreoffice.org/win86-releases again.
So far it contains the 3.x and 4.x releases and next week I'll add
the remainin
On 01.04.2023 16:45, Mike Kaganski wrote:
2. I believe we can just have *major* releases, without point releases.
I.e., 3.3.0.4; 3.4.0.1; 3.5.0.3; 3.6.0.4; 4.0.0.0.beta1; ...
Because when we bibisect, we do it to do the following bisection in the
specific repo; so the branch point is the only
Hi!
On 31.03.2023 20:50, Xisco Fauli wrote:
I recreated the bisect repository from scratch and reuploaded it to
https://bibisect.libreoffice.org/win86-releases again.
So far it contains the 3.x and 4.x releases and next week I'll add the
remaining releases.
Trying the repo :)
1. 'git check
Hello,
After playing around with msiexec and talking to Mike in IRC, I realized
some of my tweaks mentioned in my previous email were made just to allow
instdir/program/soffice.bin to launch LibreOffice. However, when using
msiexec, instdir/program/soffice.bin fails to launch LibreOffice, so
Hi Mike,
On 31/3/23 13:01, Mike Kaganski wrote:
Possibly it would make sense to use administrative install instead?
Possibly that would also make almost all the rest of the steps
unnecessary?
msiexec -a path\to\msi
The problem is that i'm on Linux so I'm using msiextract from msitools.
I
On 31.03.2023 13:43, Xisco Fauli wrote:
At least for 3.x and 4.x releases I had to do the following tweaks:
1. Extract files from msi
Possibly it would make sense to use administrative install instead?
Possibly that would also make almost all the rest of the steps unnecessary?
msiexec -a
Hello,
On 31/3/23 12:30, Mike Kaganski wrote:
Could you please describe, which tweaks were needed? In my experience,
there should be nothing needed on Windows; even StarOffice 5.2 from
2000 works without problems
At least for 3.x and 4.x releases I had to do the following tweaks:
1. Extract
On 31.03.2023 12:51, Xisco Fauli wrote:
Recently I've been working on a script[1] that creates a bisect
repository containing all the LibreOffice releases for Windows.
This might help to quickly identify in which version an issue was
introduced without the need to have all the bisect repositor
12 matches
Mail list logo
