Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Kendy,

Jan Holesovsky wrote (17-06-11 21:05)
Cor Nouws píše v Pá 17. 06. 2011 v 20:00 +0200:

Not so sure if that is a wise approach.
This feature often brought no joy. Wrong information, not available
url's etc. I guess there is some work needed to make it work properly.
Either in the code, or on the server side...

I am sorry, but I don't really understand ;-)  The original question was
for which 'y' should we start recommending 3.(x+1).y, when the user has
3.x.z.

So far I tested that the thing 'behaves sensibly' - ie. does not bother
the user when the server is not available / returns 404, which is what
we want here.  The rest is just providing the right info on the server
side; the .php to do that will be something like 20-40 lines or so.  If
we find out there is something broken in 3.4.1 wrt. updates, we can just
explicitly return 404 for that version, and fix it for 3.4.2.

I have no idea why there were trouble with it in the past. After reporting few times, sometimes working correct and then not again, I just stopped. I had the impression that it was language related.

http://specs.openoffice.org/appwide/onlineupdate/Software_Update.odt
Chapter 6 Technical Specification

This is an obsolete version, the new one is
http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol

Indeed quite different. Thanks.

3) Can the URL for the download be acessible for the sysadmins? For
instance, it will be nice to point the upgrade package to an company
internal server rather than the internet (same xcd as above, with the
url)

        These other features should be easy enough to implement; and it'd be
great to have someone working on them - patches gratefully received.

The mere wish to have someone making a feature ready to use, is not
enough argument to put in a feature that is not ready to use, IMO.

I overlooked this, sorry.  So it is configurable, just change the
UpdateURL value in versionrc / version.ini, and you are done.

Plus that the specs show that there is work to be done on the server side..

We are not using the Hamburg server side for this at all; I have script
that will do it in my head, now just to type it ;-)

If that is done before the release, it's ok of course.
And indeed there is no version available to point to immediately after the release of 3.4.1. So there is another month. And then, when 3.5. releases come, there must be a policy on if/when/how to point from 3.4.x to 3.5.x

It is important though that it is clear that those have to be in place timely and not 'later' or 'when someone comes with a patch'.

Kind regards,
Cor
--
 - Cor
 - http://nl.libreoffice.org


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.