The binaries are not in the web repo, but directly on sundries01. Releng sync them out and we point to them, so I guess this is probably a question for releng folks.

We can probably find a solution also in the websites repo. A solution could be to use a variable in the binary path and use this variable also in a text file or whatever. The tool could point to it and parse just these numbers.

We can probably find a solution also in the websites repo. A solution could be to use a variable in the binary path and use this variable also in a text file or whatever. The tool could point to it and parse just these numbers.

Yeah, that's exactly what I was thinking. We want this synced up with when the website is live, anyway, not with whatever releng is doing. :)

As a bonus, that'll make it slightly easier to update the page when we do do an update, right? (We're discussing releasing MediaWriter updates when they're ready, not necessarily tied to the GA cycle.)

As a bonus, that'll make it slightly easier to update the page when we do do an update, right? (We're discussing releasing MediaWriter updates when they're ready, not necessarily tied to the GA cycle.)

Well, yes and no. We need releng to make the binary and sync it out to sundries before we can point to it. For example I see a tag for MediaWriter of 4.0.8, while websites still have 4.0.7 and nobody built the latest version.

I'm envisioning a workflow like this:

1. Fedora Media Writer developers release new version, say this one should go on the website
2. Release Engineering builds it
3. QA tests it
4. Once QA says it's good, release engineering puts it in the place it goes — sundries, I guess. :)
5. Someone tells the websites team to do the update (files a ticket, presumably)
6. That happens. :)
7. When someone runs Fedora Media Writer, it checks the web page to see if there's a newer version, and notifies the user if there is

I don't want 7 happening before the other stuff.

I assume it will just give a link to the downloads page, not actually try to download it. But that's up to the FMW devs, really.

Yes, this is a bit manual but actually we don't really have an option to make this more automated. I'm fine with that, we can easily update the file once we get the OK from "someone" who files a ticket.
The version could be in https://getfedora.org/static/fmw-version.txt and would help us to keep the binaries updated also on the download pages. Fmw can check this file and if it gets a newer version update it with the binary in https://getfedora.org/fmw/

For a process like this, probably should have an SOP documented so steps don't get missed along the way. The best solution would be automated, of course, but it's not always possible. Perhaps that SOP should be held with other rel-eng SOPs, or split in terms of accountability, part for rel-eng and part for infra/websites?

For a process like this, probably should have an SOP documented so steps don't get missed along the way. The best solution would be automated, of course, but it's not always possible. Perhaps that SOP should be held with other rel-eng SOPs, or split in terms of accountability, part for rel-eng and part for infra/websites?
+1

Not sure if this is already a solution, but if we want to go for that until we find something more automated, we should close this ticket and add this to our docs on pagure.

In terms of the file format of the version file, I don't really have a preference - either a plaintext file or a JSON is fine (I'd probably not go for XML, especially considering we already use JSONs for the release metadata). JSON would probably be even better, if for example at some point in the future we decide it'd be good to also include some information about why is it a good idea to fetch the newer version.

FMW will then point the user to the website and they will install the update manually if they decide to. I'm not going to force the update on anyone.

So what's the status on this, please? Who should I poke about it so I can finish the next FMW release that'll contain this feature?

@mbriza Do you have a suggested JSON file? I think we can probably just go ahead and create one for the current version and submit a PR against https://pagure.io/fedora-websites/blob/master/f/getfedora.org/static

Hello, it could be either of the following jsons for the current version. Releng or websites can choose whichever format suits them better.
fileUrl points directly to the installer file and url points to where it should open the browser for the user for the download (which is for now the preferred way to do it)

fmw-version.json
fmw-version-alt.json

I can put it in https://stg.getfedora.org/static to let you do some tests, but not before evening EU time.

Ok, that would be great

Ok this is working in staging now and will be moved to production at F26 Alpha release date.

For new versions in the future please file a new ticket, so we can update the json file and the workstation webpage.

Thanks.

Thanks Robyduck!