Download links in the website

[atom-community]

Download links in the website

[aminya]

it would be nice to:

• limit the download choices to only 3 buttons (eg. installer for Windows, installer for Linux, installer for Mac) on the home page;
• specify on the home page that you are offering this entire community-maintained fork of Atom and not only some packages. Now that Atom is being abandoned, people is likely searching for a replacement which will be kept up-to-date.

If you need help with the layout, feel free to ask and I'll happily lend a hand.

Originally posted by @LorenzoAncora in atom-community/atom#456 (comment)

[LorenzoAncora]

[...] it is otherwise unmaintained by the original author, per my discussion with @autumnblazey. [...] I can go ahead and make a PR adding it.

@DeeDeeG if you do, please the link in the footer of the page, as a build control panel is clearly not something intended for end users, who could remain confused and desist. I suggest to make sure the first download links the visitors see are those for the latest working releases for Linux, Windows, Mac, ... . Just big, simple download buttons.

Example of what I mean by download buttons:

[DeeDeeG]

Hi, I am in touch with the original author of that repo.

She said she is okay with atom-community adding a link to that dashboard, and atom-community org can fork the repo and continue work on it that way, but it is otherwise unmaintained by the original author, per my discussion with @autumnblazey.

(I had meant to ask her before suggesting the link be added, but I forgot to ask first before making the suggestion. That's my mistake.)

[DeeDeeG]

Since I am the one who mentioned adding the link, I can go ahead and make a PR adding it.

[DeeDeeG]

That sounds like a good idea...

It is theoretically doable by querying and processing the Azure Pipelines API, much like the binaries dashboard I mentined does, but I am not a skilled web developer, so I would not be able to easily do that myself. So, lacking the skills/time for this, I don't plan to code up such a feature myself.

Note that no builds are "passing" at the moment until this CI step is updated to work at this fork again (skip attempting to upload artifacts to Azure Storage, since we don't have a (paid) Azure Storage account to auth to and upload artifacts to. We can just upload to GitHub releases when the time comes for that anyway.)

Until that is fixed, we can't really discern which build is "working", we would basically have to just serve the latest one available.

[LorenzoAncora]

I am not a skilled web developer […] lacking the skills/time for this, I don't plan to code up such a feature myself. […] Note that no builds are "passing" at the moment until this CI step is updated […] we don't have a (paid) Azure Storage account to auth to and upload artifacts to. We can just upload to GitHub releases when the time comes for that anyway. […] Until that is fixed, we can't really discern which build is "working", we would basically have to just serve the latest one available.

@DeeDeeG I wrote of releases, not builds. On your official website you obviously don't want users to get an unstable version, but instead something you've already tested and intentionally released. Development builds are for developers and power users, releases are for end users and is what visitors expect to get from a download button. Unless you write otherwise near the download button, visitors will suppose they are downloading a stable release.
In practice, there is no need to use any API, you just publish a direct link to the installer of the latest public release already uploaded somewhere safe (eg. GitHub or a file hosting) and change the version number under the buttons consequently. You can choose to do that 4 or 6 times a year, there is no need to publish releases continuously! :-)
This is something important which after all is better be done manually, as publishing by error something inappropriate or of low quality (eg. prone to crashes) would negatively impact the reputation of the project.