Issue for 4.1.4 and MacOS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Jim Jagielski
It would be easy to bump the build number 414m6 just for macOS.
Of course, the date is also changed, even if we keep the same
build number.

I am up for whatever makes sense. The issue is that it's
not a code "problem" at all.

> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>
>
>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>
>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>
> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>
> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>
> Regards,
> Dave
>
>>
>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>> If we replace then how would those people know to upgrade?
>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>> Regards,
>>> Dave
>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>
>>>> Question: Assuming we have "correction" builds available,
>>>> what do we do? Simply replace the online version with
>>>> these?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Matthias Seidel
In reply to this post by Dave Fisher
Am 31.10.2017 um 18:52 schrieb Dave Fisher:
>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>
>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.

My $ 0.02:
The date would be sufficient.
A new build number means a new build and I don't like the idea to
confuse 95% of our users (Windows and Linux) with a "new" version, where
not a single line of code was changed.
Rebuild the mac version and make an announcement/press release to let
the people know about it.

>
> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.

macOS update notification (4.1.3 -> 4.1.4) is on hold until this issue
is fixed.
But people can always download directly from our download page, maybe we
should put a notice there?

Regards, Matthias

>
> Regards,
> Dave
>
>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>> If we replace then how would those people know to upgrade?
>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>> Regards,
>>> Dave
>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>
>>>> Question: Assuming we have "correction" builds available,
>>>> what do we do? Simply replace the online version with
>>>> these?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Jim Jagielski
In reply to this post by Jim Jagielski
Actually, it looks like buildid (9788) is likely
should also be bumped, looking at the way downloads
are done... Do linux and Windows would be m5(9788)
and mac would be m5(9789) or m6(9789)

I am *guessing* that the m# is SVN related
and the buildid number is courtesy build # related??

> On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:
>
> It would be easy to bump the build number 414m6 just for macOS.
> Of course, the date is also changed, even if we keep the same
> build number.
>
> I am up for whatever makes sense. The issue is that it's
> not a code "problem" at all.
>
>> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>>
>>
>>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>>
>>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>>
>> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>>
>> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>>
>> Regards,
>> Dave
>>
>>>
>>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>>> If we replace then how would those people know to upgrade?
>>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>>> Regards,
>>>> Dave
>>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>>
>>>>> Question: Assuming we have "correction" builds available,
>>>>> what do we do? Simply replace the online version with
>>>>> these?
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Dave Fisher
In reply to this post by Matthias Seidel

On Oct 31, 2017, at 11:05 AM, Matthias Seidel <[hidden email]> wrote:

Am 31.10.2017 um 18:52 schrieb Dave Fisher:
On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:

I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.

My $ 0.02:
The date would be sufficient.
A new build number means a new build and I don't like the idea to
confuse 95% of our users (Windows and Linux) with a "new" version, where
not a single line of code was changed.
Rebuild the mac version and make an announcement/press release to let
the people know about it.

Jim is mentioning a different id for the build from the one that drives the upgrade:


4.1.4 OpenOffice_4 9788 https://www.openoffice.org/download en-US ast bg ca ca-XR ca-XV cs da de el en-GB es eu fi fr gd gl he hi hu it ja km ko lt nb nl pl pt pt-BR ru sk sl sr sv ta th tr vi zh-CN zh-TW


9788 is different from 414m5 or 414m6.

Jim - I think that 414



I would like to know what Andrea and Matthias think since they have been working with the upgrade system.

macOS update notification (4.1.3 -> 4.1.4) is on hold until this issue
is fixed.
But people can always download directly from our download page, maybe we
should put a notice there?

Regards, Matthias


Regards,
Dave

On 10/31/2017 9:30 AM, Dave Fisher wrote:
There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
If we replace then how would those people know to upgrade?
This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
Regards,
Dave
On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:

Question: Assuming we have "correction" builds available,
what do we do? Simply replace the online version with
these?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Dave Fisher
Sorry hit the command key and track pad at the same time and sent before done.

On Oct 31, 2017, at 11:10 AM, Dave Fisher <[hidden email]> wrote:


On Oct 31, 2017, at 11:05 AM, Matthias Seidel <[hidden email]> wrote:

Am 31.10.2017 um 18:52 schrieb Dave Fisher:
On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:

I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.

My $ 0.02:
The date would be sufficient.
A new build number means a new build and I don't like the idea to
confuse 95% of our users (Windows and Linux) with a "new" version, where
not a single line of code was changed.
Rebuild the mac version and make an announcement/press release to let
the people know about it.

Jim is mentioning a different id for the build from the one that drives the upgrade:


4.1.4 OpenOffice_4 9788 https://www.openoffice.org/download en-US ast bg ca ca-XR ca-XV cs da de el en-GB es eu fi fr gd gl he hi hu it ja km ko lt nb nl pl pt pt-BR ru sk sl sr sv ta th tr vi zh-CN zh-TW


9788 is different from 414m5 or 414m6.

Jim - I think that 414

I think that changing to 414m6 would be helpful.

Regards,
Dave




I would like to know what Andrea and Matthias think since they have been working with the upgrade system.

macOS update notification (4.1.3 -> 4.1.4) is on hold until this issue
is fixed.
But people can always download directly from our download page, maybe we
should put a notice there?

Regards, Matthias


Regards,
Dave

On 10/31/2017 9:30 AM, Dave Fisher wrote:
There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
If we replace then how would those people know to upgrade?
This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
Regards,
Dave
On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:

Question: Assuming we have "correction" builds available,
what do we do? Simply replace the online version with
these?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]






signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Rory O'Farrell
In reply to this post by Jim Jagielski
On Tue, 31 Oct 2017 14:09:46 -0400
Jim Jagielski <[hidden email]> wrote:

> Actually, it looks like buildid (9788) is likely
> should also be bumped, looking at the way downloads
> are done... Do linux and Windows would be m5(9788)
> and mac would be m5(9789) or m6(9789)

When a decision is reached and the new Mac version is ready for download, I will post a notice on the Forum advising Mac owners to install the corrected version

Rory

>
> I am *guessing* that the m# is SVN related
> and the buildid number is courtesy build # related??
> > On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:
> >
> > It would be easy to bump the build number 414m6 just for macOS.
> > Of course, the date is also changed, even if we keep the same
> > build number.
> >
> > I am up for whatever makes sense. The issue is that it's
> > not a code "problem" at all.
> >
> >> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
> >>
> >>
> >>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
> >>>
> >>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
> >>
> >> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
> >>
> >> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
> >>
> >> Regards,
> >> Dave
> >>
> >>>
> >>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
> >>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
> >>>> If we replace then how would those people know to upgrade?
> >>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
> >>>> Regards,
> >>>> Dave
> >>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
> >>>>>
> >>>>> Question: Assuming we have "correction" builds available,
> >>>>> what do we do? Simply replace the online version with
> >>>>> these?
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Rory O'Farrell <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Jim Jagielski
So the only thing that will indicate the new version will
be an updated date in the About page?

> On Oct 31, 2017, at 2:19 PM, Rory O'Farrell <[hidden email]> wrote:
>
> On Tue, 31 Oct 2017 14:09:46 -0400
> Jim Jagielski <[hidden email] <mailto:[hidden email]>> wrote:
>
>> Actually, it looks like buildid (9788) is likely
>> should also be bumped, looking at the way downloads
>> are done... Do linux and Windows would be m5(9788)
>> and mac would be m5(9789) or m6(9789)
>
> When a decision is reached and the new Mac version is ready for download, I will post a notice on the Forum advising Mac owners to install the corrected version
>
> Rory
>
>>
>> I am *guessing* that the m# is SVN related
>> and the buildid number is courtesy build # related??
>>> On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:
>>>
>>> It would be easy to bump the build number 414m6 just for macOS.
>>> Of course, the date is also changed, even if we keep the same
>>> build number.
>>>
>>> I am up for whatever makes sense. The issue is that it's
>>> not a code "problem" at all.
>>>
>>>> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>>>>
>>>>
>>>>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>>>>
>>>>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>>>>
>>>> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>>>>
>>>> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>>
>>>>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>>>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>>>>> If we replace then how would those people know to upgrade?
>>>>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>>>>> Regards,
>>>>>> Dave
>>>>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>>>>
>>>>>>> Question: Assuming we have "correction" builds available,
>>>>>>> what do we do? Simply replace the online version with
>>>>>>> these?
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Rory O'Farrell <[hidden email] <mailto:[hidden email]>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Dave Fisher
In reply to this post by Jim Jagielski
Hi Jim,


80 elif [ $idx -eq 2 ]; then
81 productbuildid[$version]=$data

It looks like a version can only have one build id.

It would be safe to bump to m6(9788) but it is not so safe to do m6(9789). Unless generate-update-feed.sh is updated.

Regards,
Dave

On Oct 31, 2017, at 11:09 AM, Jim Jagielski <[hidden email]> wrote:

Actually, it looks like buildid (9788) is likely
should also be bumped, looking at the way downloads
are done... Do linux and Windows would be m5(9788)
and mac would be m5(9789) or m6(9789)

I am *guessing* that the m# is SVN related
and the buildid number is courtesy build # related??
On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:

It would be easy to bump the build number 414m6 just for macOS.
Of course, the date is also changed, even if we keep the same
build number.

I am up for whatever makes sense. The issue is that it's
not a code "problem" at all.

On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:


On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:

I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.

I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.

I would like to know what Andrea and Matthias think since they have been working with the upgrade system.

Regards,
Dave


On 10/31/2017 9:30 AM, Dave Fisher wrote:
There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
If we replace then how would those people know to upgrade?
This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
Regards,
Dave
On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:

Question: Assuming we have "correction" builds available,
what do we do? Simply replace the online version with
these?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Marcus (OOo)
In reply to this post by Jim Jagielski
Am 31.10.2017 um 19:09 schrieb Jim Jagielski:
> Actually, it looks like buildid (9788) is likely
> should also be bumped, looking at the way downloads
> are done... Do linux and Windows would be m5(9788)
> and mac would be m5(9789) or m6(9789)
>
> I am *guessing* that the m# is SVN related
> and the buildid number is courtesy build # related??
>> On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:

the new builds would be downloadable as long as they have the same
version number (4.1.4) inside the filenames.

It's just that the new build ID or milestone number cannot be displayed
on the download webpage as it has to be the same for every platform.

But I think that this shouldn't be a problem. When the Mac users
download the files, they get the new files and should be happy.

Marcus



>> It would be easy to bump the build number 414m6 just for macOS.
>> Of course, the date is also changed, even if we keep the same
>> build number.
>>
>> I am up for whatever makes sense. The issue is that it's
>> not a code "problem" at all.
>>
>>> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>>>
>>>
>>>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>>>
>>>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>>>
>>> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>>>
>>> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>>>> If we replace then how would those people know to upgrade?
>>>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>>>> Regards,
>>>>> Dave
>>>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>>>
>>>>>> Question: Assuming we have "correction" builds available,
>>>>>> what do we do? Simply replace the online version with
>>>>>> these?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Dave Fisher
Hi Marcus,

The implication is that build id, milestone, binaries and svn version must be in sync across all of OpenOffice.

Jim should leave the values the same as the prior release.

So 75,000 plus users of Mac may be in limbo not knowing about the update until 4.2 comes out. We will need to announce the situation when we are ready.

We won’t do 4.1.5, but then should try to get 4.2 done pretty soon.

We can look into the download pages to see about changes for 4.2 allowing different builds for different platforms?

This seems the most pragmatic approach given current constraints. Do we all agree?

Regards,
Dave

> On Oct 31, 2017, at 11:29 AM, Marcus <[hidden email]> wrote:
>
> Am 31.10.2017 um 19:09 schrieb Jim Jagielski:
>> Actually, it looks like buildid (9788) is likely
>> should also be bumped, looking at the way downloads
>> are done... Do linux and Windows would be m5(9788)
>> and mac would be m5(9789) or m6(9789)
>> I am *guessing* that the m# is SVN related
>> and the buildid number is courtesy build # related??
>>> On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:
>
> the new builds would be downloadable as long as they have the same version number (4.1.4) inside the filenames.
>
> It's just that the new build ID or milestone number cannot be displayed on the download webpage as it has to be the same for every platform.
>
> But I think that this shouldn't be a problem. When the Mac users download the files, they get the new files and should be happy.
>
> Marcus
>
>
>
>>> It would be easy to bump the build number 414m6 just for macOS.
>>> Of course, the date is also changed, even if we keep the same
>>> build number.
>>>
>>> I am up for whatever makes sense. The issue is that it's
>>> not a code "problem" at all.
>>>
>>>> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>>>>
>>>>
>>>>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>>>>
>>>>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>>>>
>>>> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>>>>
>>>> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>>
>>>>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>>>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>>>>> If we replace then how would those people know to upgrade?
>>>>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>>>>> Regards,
>>>>>> Dave
>>>>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>>>>
>>>>>>> Question: Assuming we have "correction" builds available,
>>>>>>> what do we do? Simply replace the online version with
>>>>>>> these?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Marcus (OOo)
Am 31.10.2017 um 19:46 schrieb Dave Fisher:
> The implication is that build id, milestone, binaries and svn version must be in sync across all of OpenOffice.

which is the case already. ;-)

> Jim should leave the values the same as the prior release.
>
> So 75,000 plus users of Mac may be in limbo not knowing about the update until 4.2 comes out. We will need to announce the situation when we are ready.
>
> We won’t do 4.1.5, but then should try to get 4.2 done pretty soon.
>
> We can look into the download pages to see about changes for 4.2 allowing different builds for different platforms?
>
> This seems the most pragmatic approach given current constraints. Do we all agree?

sure, we can split up things. But this would createa nightmare for the
support/forums guys when every platform (language aloso ;-) ) will/can
have different metadata.

So, the problem is not the download script. I'm sure that this can be
enhanced. But do we really want to go this step? I'm not so sure.

Marcus



>> On Oct 31, 2017, at 11:29 AM, Marcus <[hidden email]> wrote:
>>
>> Am 31.10.2017 um 19:09 schrieb Jim Jagielski:
>>> Actually, it looks like buildid (9788) is likely
>>> should also be bumped, looking at the way downloads
>>> are done... Do linux and Windows would be m5(9788)
>>> and mac would be m5(9789) or m6(9789)
>>> I am *guessing* that the m# is SVN related
>>> and the buildid number is courtesy build # related??
>>>> On Oct 31, 2017, at 2:03 PM, Jim Jagielski <[hidden email]> wrote:
>>
>> the new builds would be downloadable as long as they have the same version number (4.1.4) inside the filenames.
>>
>> It's just that the new build ID or milestone number cannot be displayed on the download webpage as it has to be the same for every platform.
>>
>> But I think that this shouldn't be a problem. When the Mac users download the files, they get the new files and should be happy.
>>
>> Marcus
>>
>>
>>
>>>> It would be easy to bump the build number 414m6 just for macOS.
>>>> Of course, the date is also changed, even if we keep the same
>>>> build number.
>>>>
>>>> I am up for whatever makes sense. The issue is that it's
>>>> not a code "problem" at all.
>>>>
>>>>> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>>>>>
>>>>>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>>>>>
>>>>> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>>>>>
>>>>> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>>
>>>>>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>>>>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>>>>>> If we replace then how would those people know to upgrade?
>>>>>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>>>>>> Regards,
>>>>>>> Dave
>>>>>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Question: Assuming we have "correction" builds available,
>>>>>>>> what do we do? Simply replace the online version with
>>>>>>>> these?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Andrea Pescetti-2
In reply to this post by Dave Fisher
Dave Fisher wrote:
> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.

This is just a bug. A bad bug, that teaches us that (let alone the
source code) we should document not only the configure switches but also
key details of the environment.

As for the resolution, I would follow our standard practices, nothing
special:

1. We make sure the bug is fixed, and document in all detail what
happened on https://bz.apache.org/ooo/show_bug.cgi?id=127568 - note that
we are still at this stage at the moment, and we can't be sure whether
this is a build-only issue (as it seems to be) or it requires code
changes or at least Makefile changes.

2. We seriously test the new builds since it's clear that Mac is the
most problematic platform, starting with the bug reported by Roberto for
RC4, then the inability to save documents in the first attempt of RC5,
then this dataloss issue in the released 4.1.4.

3. We simply release 4.1.5. There is nothing preventing us from doing
so. It will take a couple weeks, maybe we will find another couple
regressions and fix them in the meantime. For example (this is not a
regression but a UX problem) we'll want to include the latest English
dictionary. There's nothing wrong in making a new release one month
after 4.1.4 rather than one year after it!

In terms of the update feed, we can keep on hold the update feeds for
the 4.1.3 (and earlier) to 4.1.4 upgrade for Mac users; and once 4.1.5
is out, we will push the update as usual.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Andrea Pescetti-2
Andrea Pescetti wrote:
> In terms of the update feed, we can keep on hold the update feeds for
> the 4.1.3 (and earlier) to 4.1.4 upgrade for Mac users; and once 4.1.5
> is out, we will push the update as usual.

Another obvious thing we can do (if we are really sure that 4.1.4 for
Mac contains a dataloss bug) is to simply retire the Mac build. The
download page would suggest 4.1.4 for other platforms and 4.1.3 for Mac,
with a short explanation saying that OS X binary builds will be provided
soon (then whether this happens with "new" 4.1.4 builds or with 4.1.5 is
a detail that doesn't concern users at this time).

Files would still be on SourceForge for those who really want to
download 4.1.4, but this would still guarantee that Mac users do not
download a build known to have issues.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Matthias Seidel
Am 31.10.2017 um 23:39 schrieb Andrea Pescetti:
> Andrea Pescetti wrote:
>> In terms of the update feed, we can keep on hold the update feeds for
>> the 4.1.3 (and earlier) to 4.1.4 upgrade for Mac users; and once 4.1.5
>> is out, we will push the update as usual.

I could temporarily exchange all update feeds with versions without macOS?
Since the old ones will always lead people to the download page, even if
they only say e.g. 4.1.2 is available...

>
> Another obvious thing we can do (if we are really sure that 4.1.4 for
> Mac contains a dataloss bug) is to simply retire the Mac build. The
> download page would suggest 4.1.4 for other platforms and 4.1.3 for
> Mac, with a short explanation saying that OS X binary builds will be
> provided soon (then whether this happens with "new" 4.1.4 builds or
> with 4.1.5 is a detail that doesn't concern users at this time).

We could do that in a similar way as we tell people that 4.1.4 is not
available for OS X <= 10.6.
The logic is in
http://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/download/download.js

Regards, Matthias

>
> Files would still be on SourceForge for those who really want to
> download 4.1.4, but this would still guarantee that Mac users do not
> download a build known to have issues.
>
> Regards,
>   Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Andrea Pescetti-2
Matthias Seidel wrote:
> Am 31.10.2017 um 23:39 schrieb Andrea Pescetti:
>> Andrea Pescetti wrote:
>>> In terms of the update feed, we can keep on hold the update feeds for
>>> the 4.1.3 (and earlier) to 4.1.4 upgrade for Mac users; and once 4.1.5
>>> is out, we will push the update as usual.
> I could temporarily exchange all update feeds with versions without macOS?

This is overkill. Those users have ignored update notifications for at
least one year anyway, so the impact would be minimal. 4.1.3 users and
new users are the primary target.

>> download page would suggest 4.1.4 for other platforms and 4.1.3 for
>> Mac, with a short explanation saying that OS X binary builds will be
>> provided soon (then whether this happens with "new" 4.1.4 builds or
>> with 4.1.5 is a detail that doesn't concern users at this time).
>
> We could do that in a similar way as we tell people that 4.1.4 is not
> available for OS X <= 10.6.
> The logic is in
> http://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/download/download.js

I thought we had some easier way to just "cap" OS X to 4.1.3, but Marcus
probably knows best how we could do it - provided we want to, of course;
it's just a proposal for the time being, and I can't even verify the
issue directly.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Matthias Seidel
Am 01.11.2017 um 00:22 schrieb Andrea Pescetti:

> Matthias Seidel wrote:
>> Am 31.10.2017 um 23:39 schrieb Andrea Pescetti:
>>> Andrea Pescetti wrote:
>>>> In terms of the update feed, we can keep on hold the update feeds for
>>>> the 4.1.3 (and earlier) to 4.1.4 upgrade for Mac users; and once 4.1.5
>>>> is out, we will push the update as usual.
>> I could temporarily exchange all update feeds with versions without
>> macOS?
>
> This is overkill. Those users have ignored update notifications for at
> least one year anyway, so the impact would be minimal. 4.1.3 users and
> new users are the primary target.
It is not so much work for me to do...

And you would be surprised how many updates there are every day from
older versions via update feed.
I can see it in real time with "Google Analytics". ;-)

>
>>> download page would suggest 4.1.4 for other platforms and 4.1.3 for
>>> Mac, with a short explanation saying that OS X binary builds will be
>>> provided soon (then whether this happens with "new" 4.1.4 builds or
>>> with 4.1.5 is a detail that doesn't concern users at this time).
>>
>> We could do that in a similar way as we tell people that 4.1.4 is not
>> available for OS X <= 10.6.
>> The logic is in
>> http://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/download/download.js
>>
>
> I thought we had some easier way to just "cap" OS X to 4.1.3, but
> Marcus probably knows best how we could do it - provided we want to,
> of course; it's just a proposal for the time being, and I can't even
> verify the issue directly.
Yes, Marcus knows best. But I think this would be the best way to
implement it.

Regards, Matthias

>
> Regards,
>   Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Jim Jagielski
In reply to this post by FR web forum
I have replacement macOS builds available which solve this problem.

There were no source code changes required: it was simply an issue
with the build environment itself. As such, these new builds have
the same version numbers, just different build dates.

I'd like to propose that we open up these builds for additional
macOS/OSX testing before we "replace" the current builds.

Comments? Feedback? Suggestions?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Dave Fisher

> On Nov 1, 2017, at 8:04 AM, Jim Jagielski <[hidden email]> wrote:
>
> I have replacement macOS builds available which solve this problem.
>
> There were no source code changes required: it was simply an issue
> with the build environment itself. As such, these new builds have
> the same version numbers, just different build dates.
>
> I'd like to propose that we open up these builds for additional
> macOS/OSX testing before we "replace" the current builds.
+1 - I’ve done a smoke test and can confirm that the particular bug with saving links is fixed.

>
> Comments? Feedback? Suggestions?

I am for disclosing the url so that the new build can be tested quickly. We should put the link on dev@, users@ and qa@ - any others?

I think we wait on the forums until we confirm the replacement.

How long should we allow for testing?

Regards,
Dave

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Kay Schenk-2
In reply to this post by Jim Jagielski
On 10/31/2017 11:03 AM, Jim Jagielski wrote:
> It would be easy to bump the build number 414m6 just for macOS.
> Of course, the date is also changed, even if we keep the same
> build number.

This makes more sense to me than a complete 4.1.5 (for all?) when this
build issue just applies to MacOS.  But the update feed script would
need some tweaking.

>
> I am up for whatever makes sense. The issue is that it's
> not a code "problem" at all.
>
>> On Oct 31, 2017, at 1:52 PM, Dave Fisher <[hidden email]> wrote:
>>
>>
>>> On Oct 31, 2017, at 9:51 AM, Patricia Shanahan <[hidden email]> wrote:
>>>
>>> I do not know if this is the right choice, but we should include doing both in our thinking. Rebuild 4.1.4 for Mac only, test, and upload as soon as possible. Meanwhile, create, test, and vote on 4.1.5, to pick up the upgrade service.
>> I agree this what we need to think about. With the new 4.1.4 route we should make sure that we can tell the difference between the bad original and the repaired build. Is the date sufficient or would build number be better? I really don’t like the idea of people being confused about what they need to do to fix issues. Right now the message is to downgrade to 4.1.3.
>>
>> I would like to know what Andrea and Matthias think since they have been working with the upgrade system.
>>
>> Regards,
>> Dave
>>
>>> On 10/31/2017 9:30 AM, Dave Fisher wrote:
>>>> There have been over 1,000,000 downloads of 4.1.4.  How many were of the bad Mac version?
>>>> If we replace then how would those people know to upgrade?
>>>> This issue makes me think we need to have this be a new version so that we can setup the upgrade service correctly.
>>>> Regards,
>>>> Dave
>>>>> On Oct 31, 2017, at 9:21 AM, Jim Jagielski <[hidden email]> wrote:
>>>>>
>>>>> Question: Assuming we have "correction" builds available,
>>>>> what do we do? Simply replace the online version with
>>>>> these?
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
------------------------------------------
MzK

"Only the truth will save you now."
       -- Ensei Tankado, "Digital Fortress"


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue for 4.1.4 and MacOS

Marcus (OOo)
In reply to this post by Matthias Seidel
Am 01.11.2017 um 00:29 schrieb Matthias Seidel:

> Am 01.11.2017 um 00:22 schrieb Andrea Pescetti:
>> Matthias Seidel wrote:
>>> Am 31.10.2017 um 23:39 schrieb Andrea Pescetti:
>>>> Andrea Pescetti wrote:
>>>>> In terms of the update feed, we can keep on hold the update feeds for
>>>>> the 4.1.3 (and earlier) to 4.1.4 upgrade for Mac users; and once 4.1.5
>>>>> is out, we will push the update as usual.
>>> I could temporarily exchange all update feeds with versions without
>>> macOS?
>>
>> This is overkill. Those users have ignored update notifications for at
>> least one year anyway, so the impact would be minimal. 4.1.3 users and
>> new users are the primary target.
>
> It is not so much work for me to do...
>
> And you would be surprised how many updates there are every day from
> older versions via update feed.
> I can see it in real time with "Google Analytics". ;-)
>
>>
>>>> download page would suggest 4.1.4 for other platforms and 4.1.3 for
>>>> Mac, with a short explanation saying that OS X binary builds will be
>>>> provided soon (then whether this happens with "new" 4.1.4 builds or
>>>> with 4.1.5 is a detail that doesn't concern users at this time).
>>>
>>> We could do that in a similar way as we tell people that 4.1.4 is not
>>> available for OS X <= 10.6.
>>> The logic is in
>>> http://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/download/download.js
>>>
>>
>> I thought we had some easier way to just "cap" OS X to 4.1.3, but
>> Marcus probably knows best how we could do it - provided we want to,
>> of course; it's just a proposal for the time being, and I can't even
>> verify the issue directly.
>
> Yes, Marcus knows best. But I think this would be the best way to
> implement it.

fix is ready and working locally.

Text in the red error box:

Problem: Apache OpenOffice 4.1.4 is not available for OS X (version >=
10.7) (DMG).
Solution: Please select version 4.1.0 or newer.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12345