On 22/03/2019 19:04, Guilhem Moulin wrote:
>
> As the command output suggests, yes. Or at least that's what I propose,
> assuming releng accept to maintain that map.
Let's have our fingers crossed hoping this will be possible to
implement/keep over the long term then :)
>
> Depends what “this” refers to. There is no dictionary mapping
> ‘fresh’/‘still’ to download urls, let alone a 3XY redirect. But if you
> provide your build and a more recent version is available for that
> flavor, you get some information about that update, incl. its build ID
> and version number
Hum ok. But in your example you specified a 6.0.x build and the server
answered the user should download 6.1.5.
This is weird because if someone has installed the 6.0 branch when that
one was the *fresh one*, he won't be proposed to download 6.2.2.
I'm thus wondering:
* how the system performs the match between branches and how he keeps
track of the branches (see issue described just above ^)
* and (more interesting for my use case), how to have a build string
that will always work. i.e. a build string that will answer with the
latest version of the still branch and a build string that will
answer with the latest version of the fresh branch. Because at
chocolatey, the update script won't change (as the build id I'll fake).
>
> curl -sSA "LibreOffice 6.0.7.3 (dc89aa7a9eabfd848af146d5086077aeed2ae4a5;
> Windows; x86; )" \
> https://update.libreoffice.org/check.php | xmlstarlet sel -T -t -v
> '/inst:description/inst:version'
Ok perfect. Understood. I didn't know about xmlstarlet btw. Great tool!
--
William Gathoye
<[email protected]>
--
To unsubscribe e-mail to: [email protected]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
