Remove the releases from GitHub

[marcelstoer]

With my PR #560 the pre_build directory was removed (only on master and not on dev 😞 ). I believe we should also drop all binaries in https://github.com/nodemcu/nodemcu-firmware/releases.

Instead we could add a "synthetical" release that contains only a README-style document that explains why there are no pre-built binaries (anymore) and suggest ways how to build the firmware.

Whenever I come across a blog post or the like which explains how to download an NodeMCU release from our GitHub repo I leave a comment or contact the author and tell them why it isn't such a good idea (anymore).

[TerryE]

Marcel, I personally believe that a repository should be normalised; that is only contain originating source material and not derived build materials. Therefore we should not have a nodemcu-firmware/releases folder (or a nodemcu-firmware/sdk folder for that matter, but I'll address that separately). The correct place for releases is somewhere like http://nodemcu.com/releases possibly with a mirror on http://nodemcu-build.com/releases (or /prebuilt) and that our documentation should refer to these.

In the former case I am sure that zeroday could set up a SFTP overlay onto http://nodemcu.com/releases for the committers here so we can have upload access to this publicly accessible binary repository.

Incidentally I suspect that if you do an analysis of your build requests, they probably cluster quite well and that perhaps 4 or 5 standard prebuilts will cover 90% of requests, so having these prebuilt would mean that the significant majority of new users could simply download a prebuilt rather than doing a custom request.

[nodemcu]

First of all, the online build tool is great! thanks!
At the very beginning, there is a download link for bin at website nodemcu.com.
and also a post for latest prebuilt bin in bbs.nodemcu.com.
but I found github release an easy way to deploy. and a solid place to download.
but as the binary grows, the built bin now is bigger than 512k if everything included.
so, I was thinking that, can we choose a minimal build among all these modules?
say, no chip specific module in the default(minimum) build?
sure I can make some download links at nodemcu.com/releases if it is a good place,
and a sftp upload method for committers.

[karrots]

Any reason binary releases just stay in the github releases section like they are now? Travis-ci is setup and could be extended to build 2-3 different firmware options to attach with the release. Travis-ci does support many other providers if its better to self host on S3 or something.

[TerryE]

Any reason binary releases just stay in the github releases section like they are now?

There is a pragmatic one: the git model is incredibly network efficient for local replication if you are using non-binary objects. However git replication sucks for volatile binary objects. Essentially anyone pulling down master or dev regularly will collect of these binary objects on their local file system. Far better to have just a single MD or HTML file for releases with links and SHA1s pointing at a repository. Then all users have the links to the files and can pull the ones that they want with a single click in the browser.

[karrots]

I should clarify I am referring to _github_ releases not binary objects in the git repo. I am all on board with removing binary objects of this sort from the repo.

https://github.com/nodemcu/nodemcu-firmware/releases
https://github.com/blog/1547-release-your-software
https://help.github.com/articles/about-releases/

[marcelstoer]

I personally believe that a repository should be normalised; that is only contain originating source material and not derived build materials.

I fully agree but GitHub releases at https://github.com/nodemcu/nodemcu-firmware/releases are not part of the repository i.e. you won't have them locally if you clone the repository.

If we decide to continue proving binaries (content tbd) then GitHub releases is the perfect place to keep them.

[TerryE]

Durrrh, I am brain dead again. Releases are github extension to standard git that I've never personally used before. I learn something every day. Sorry folks

[jmattsson]

I could see the value of having say, minimal, default, and full releases available on github (built & released by CI), as long as there are prominent notes about the custom-build service. And if anything I'd love to see the user_config.h options exposed in a Friendly(tm) manner somehow too (possibly via a separate markdown file to provide the necessary info & settings control).

[marcelstoer]

I'd like to bring this discussion back to the original subject 😉 When @TerryE is done with #745 pre_build will be gone in master as well. That's good.

The question right now is if we also want to dump the old GitHub releases that we don't support anymore anyhow. IMO it's not sensible to keep them online and then tell people who report issues against them to go and build from dev first.

How we want to handle releases after the "clean-up actions" is a valid but entirely different question.

I'm interested what you think of my initial proposal

Instead we could add a "synthetical" release that contains only a README-style document that explains why there are no pre-built binaries (anymore) and suggest ways how to build the firmware.

[nickandrew]

I think having any modern build available in a Release is better than people downloading 0.9.6-dev_20150704 and thinking it's the latest. A minimal build could enable uart and networking and omit all device drivers. Users will quickly find when they need a driver, to go to the build service.

Also @marcelstoer, how about removing "master" option from your build service? To keep people away from master until dev is merged.

[nickandrew]

What happens when just a tag is pushed, as I suggested in #820 ?

[nodemcu]

@nickandrew When a tag is pushed, the travis-ci will build the firmware, and deploy two bin file to github releases.
as almost every module is currently enabled. it may exceed 512k.
although it is ok for a nodemcu dev-kit. but many people use ESP-01 or some modules with only 512k flash. so a beginner will brick the ESP-01.
so, we have to choose which module should be included default, to reduce demo firmware size

[ghusson2]

Following my remarks in #7771], Hmmm... thus there is no more prebuilt nodemcu... because the full firmware > 512k.

In terms of organization, an idea could be to create a dedicated repo (ex : https://github.com/nodemcu/nodemcu-firmware-releases) in order to keep the code directory clear? In terms of firmware size, the idea of 3/4 firmwares with preselected libraries is interesting (but need to present some matrix of content).

Maybe you could provide alongside a full binary with name like "nodemcu_1.4.0_bigger512k_warning.bin" with some explanation on the main readme of the dedicated repo ?

An other idea is to put a link (i don't know if it is possible in git) to the latest stable and dev releases (in order to keep the same link ind docs and backlinks - nodemcu.com) ?

[nodemcu]

in order to keep the code directory clear ?

github releases will not pollute the source code directory.

maybe build two versions firmware binary is a good idea?
like
nodemcu_full_1.4.0-tag-xxx.bin
and
nodemcu_standard(minimal)_1.4.0-tag-xxx.bin
and with download guide in readme.

github releases has a latest link. https://github.com/nodemcu/nodemcu-firmware/releases/latest
which linked to the most recently tagged releases.

[ghusson2]

github releases will not pollute the source code directory

indeed, as it was discussed, it seems to be "managed" by git

github releases has a latest link

yes and no... in fact, the link doesn't leads to download the last binary directly (example of what I think is perfect as use case : you need keepass, you go there : http://sourceforge.net/projects/keepass/ and click on download).

[marcelstoer]

@ghusson2 Please use proper quoting (https://help.github.com/articles/markdown-basics/), your comments are otherwise hard to read. I fixed it this time for you.

it seems to be "managed" by git

No, they're managed by GitHub. Please read the entire thread before adding new comments that have been discussed before in the same issue.

[ghusson2]

proper quoting

Ok, I will look at that.

No, they're managed by GitHub

Yes, sorry about confusion.

[TerryE]

We've removed the prebuilt folder from both master and dev, and agreed that we should use gihub releases. I think that this closes this issue.

[marcelstoer]

agreed that we should use gihub releases

Based on the opinions expressed in the comments above one could arrive at that conclusion. It isn't entirely clear for me though.
So, let's say we keep them (fine for me btw):

• We haven't agreed on what kind of releases we'd like to see there. -> separate issue
• I haven't heard from anybody what to do with the current but outdated binaries here on GitHub. This is the essential question I'd like to see answered in this issue. As I said in my initial description I'd like to remove them for the stated reasons.

[TerryE]

Marcel, I agree with what you say and we may need a new issue, but if so then the issue should address what the issue should its title. It really doesn't help having a thread which starts out with one theme and slowly morphs unendingly into another. Please open the new issue.

[nickandrew]

@marcelstoer The outdated binaries kept by github will cease to be a problem once newer binaries replace them. My vote is to have the automated build include only a minimal, demonstration set of modules.

[marcelstoer]

The outdated binaries kept by github will cease to be a problem once newer binaries replace them

I know but this may take weeks or months. I'm concerned about today, tomorrow and next week. However, if you all think we should keep them for download then so be it.