GitHub releases

[goliatone]

The latest release available on GitHub is 0.9.6-dev_20150704, which is pretty outdated.

There are different issues with this, one is that I know people who will download the latest release and run into problems- worst is possible mismatch between documentation and observed behavior- or run into issues that have been fixed in more recent releases.

Also, currently master is broken or partially broken for me and this happens more often than not, so having a stable release sounds like a good idea.

I'm wondering why there are no more recent releases, is keeping releases not a thing anymore?

[diegargon]

agree

[marcelstoer]

You may both be interested in reading through #788.

With #1127 we established at least a common understanding among us committers what the default configuration should be. That means we would be in a good position to provide pre-built binaries again. However, the statistics of my custom build service tell me that less than 10% of the users who build from master do actually select the default configuration. Hence, rather than people reporting that feature X in 0.9.x didn't work (because it's broken) we'd get reports that feature Y in 1.5.x was broken (due to missing required module).

currently master is broken or partially broken for me and this happens more often than not

Then please report that in separate isolated issues. Since master is 4 months old and a dev-to-master snap is just around the corner (see #1146) be sure to verify if those issues are solved in dev.

[pjsg]

I would be happy with having four firmware images:

• Integer versus float
• fits in 512k with small spiffs FS vs fits in 1M with less small FS

This recognizes that many people have 2MB systems but there may be an advantage to keeping the firmware to fit within 1M.

What happens if we turn on essentially all the modules and a couple of extra fonts?

[goliatone]

@marcelstoer Thank you for pointing me to those two issues, definitively a good background on the subject.

If the preferred way is for users to do a custom build rather than using the available releases, then it should be stated clearly. I would suggest adding a small notice regarding builds in the README.

Still, I have tow concerns:

• People using outdated builds
• Lack of stable builds snapshots

People using the outdated builds

However, the statistics of my custom build service tell me that less than 10% of the users who build from master do actually select the default configuration.

Are there stats on the downloads from the releases page? It might be that people first download the release and then find out about the custom build and only do a custom build when they need something not included in that build. That was definitively my case.

My concern is about people new to the project who are testing the waters and they just want to see something working, so they grab the latest release available.

Also, existing examples, tutorials, etc.

Stable builds

Currently there is no way to target an specific build or release, since tags are not being used either.

Some people [might] make a build and check that build with their source code in github because they have no easy way to go back to that specific build, so you find plenty of outdated builds out there.

Then please report that in separate isolated issues. Since master is 4 months old and a dev-to-master snap is just around the corner (see #1146) be sure to verify if those issues are solved in dev.

I mentioned master not working for me right now not to report it as an issue, just making a point to stress my need to be able to access stables builds.

[marcelstoer]

For more background info definitely check out the mighty #719 as well 😉

I would suggest adding a small notice regarding builds in the README.

Well, it's kinda there but the README.md is as well eagerly waiting for the next dev-to-master snap: https://github.com/nodemcu/nodemcu-firmware/blob/dev/README.md. Of course nobody reads the README.md on the dev branch.

As for pre-built binaries I totally feel the pain of this community and I do hope we find a model that works for both our users and for us committers.

Are there stats on the downloads from the releases page?

The GitHub API has them (download_count): https://api.github.com/repos/nodemcu/nodemcu-firmware/releases/tags/0.9.6-dev_20150704 It can't tell you how it developed over time, though.

making a point to stress my need to be able to access stables builds.

master is as stable as you can go but that doesn't mean bug free of course.

[diegargon]

First hello, excuse my english, and thanks for the work on this.

I begin "playing" last week with NodeMCU/ESP8266 when my first unit arrive i download the flasher for install the latest stable firmware and begin learning, since i am newbie i never want learning with a dev release and fight against learning&bugs at same time

I getting problems with docs and example code, using functions/methods give me nil errors and other things, i search that functions and i found was implement more than six months ago, i don't known what up, finally i realized the firmware install by the flasher it more than one year old! i never expect that lol. I then go to master branch, but of course same problem, its outdated, finally a install a firmware from the dev release and was fine, despite lots of errors in my code and the need of rewrite again things like my http server code for the send "problem" and other things.

In a nutshell, the stable release are very outdated and for learning using the docs its problematic, and if you guys release another stable firmware next century upgrade/change the code will not be fun.
Definitely we (newbies) and all must use dev code, the outdated stable released seems meaningless, for learning or for use.
if the docs warn that certain functions/methods/example code etc are only accessible/work using the dev release can be a good idea too for people like me (beginners)

[goliatone]

The way I see it, currently the project is in between different models of managing releases and builds, as in moving away from releases and encouraging the use of custom builds.

There are two things that could improve the current situation:

• the project should make use of tags- so you can roll back.
• nodemcu-build should provide three build options:
  • master
  • dev
  • sha/tag

If the online build tool let's me build sources from a known point in time, I can rest assured that having a fast moving master will not leave me stuck with old firmware if, for whatever reason, something makes it into master and makes it temporarily unusable.

[marcelstoer]

I think we more or less agreed that we'll keep tagging master drops from now on. Also, sooner or later I'll most likely start providing current master pre-builts on nodemcu-build.com.
-> closing this one