Flashing with default - how does the IDE get the .bin file and how is it delivered - could it have been cached? ...was I too quick

The last 24 hours something really weird happened:

A bit history:
1) A bit ago I used not yet released 1v72 (with new support of exporting anything, not just function)
2) Week or two ago I switched back to released 1v71 version
3) Two days ago I began using @DrAzzy's new AT25 EEPROM modules connecting to my FRAM. To do that, I had to load the not yet released 1v72 - but new than before loaded 1v72 - because of the E.toString() data conversion
4) After a few trials and minor changes in AT25 module code, AT25 worked with only the power cycle caveat: first read and write after power cycle failed. Adding an extra read upfront made it work nicely
5) I started the comparative analysis between the new AT25 module code and code I wrote earlier to - last but not least - figure out why the caveat.
6) This early morning (PST), minutes after 1v72 release announcement in forum, I flashed my - only one board I own - with the default flashing to get the spanking new release.
7) Right away I tested A25 again with fresh upload and it failed even after an extra read which had 'saved' me before
8) Left a few posts about the remedy of the issue
9) Disconnected board, left for work
10) Back from work - about 16 hours later - I look at the forum and try to figure out the hacks
11) Just connected, I look - for what ever reason - at the connect blurb and notice 1v71... what the heck...
12) Without thinking further, I just flash with default again and see now 1V72...

This really puzzled me because after flashing this morning after 1v72 announcement with default what I meant to be 1V72 was actually 1V71...

If I would have detected earlier, some back and forth about AT25/EEPROM would not have happen... on the other hand , cannot really understand why the new AT25 - as pulled with require("AT25") ; in the code uploaded to the board with 1v72 - made Espruino NOT to complain about the new E.toString() function used by AT25... and return (nicely and consistently 0xFF)[http://forum.espruino.com/comments/12067­790/]... no matter what...

@DrAzzy, for your - and my - peace of mind, I could not recreate the error after flashing again... I mad at me not to react right properly and test before flashing with default again (sure, I can go back to 1v71 and test... and hopefully would notice the same failures... I know for sure that I got some firmware flashed than I had on the board, because new A25 was working nice (beside the power cycle caveat).

My only explanation is: the 1v71 was still hanging out there in the browser, network, or the http server cache, and I got 'the floor model' delivered... which brings me to the question about the method / exact code the IDE issues to get the .bin file.

@Gordon, is there some reasonable explanation from your point for that?

I experienced the "flashback" bug as well!

I had a board running v72 bigram from the 23rd. Went into tools, flasher, flashed it, nothing advanced. And I was getting odd behavior.... And then I tried to convert something to a uint8array and that didn't work, and then I reconnected and realized I was on v71 again. But then I saw the little notice in the upper right corner saying there was an update, and went through flasher again, and it flashed.

But at the time, I scratched my head, and wondered if I'd done something dumb (it's been known to happen), and ignored it once I got the right firmware flashed. The fact that you saw the exact same thing points to a larger issue.

I'll bet it has something to do with the fact that we were already running a board with v72, and that made the IDE not think we needed to update... and hence not download the new firmware?

Well, all I can think is it's browser caching. When you connect, the web IDE looks at process.env to figure out which board you have, then looks at http://www.espruino.com/json/ESPRUINOBOA­RD.json. In there it's got the current version and a link to the current firmware.

Having said that, the file is served up with the relevant headers to say 'don't cache' - so if it is being kept it really shouldn't be.

it has something to do with the fact that we were already running a board with v72, and that made the IDE not think we needed to update...

Indeed, that could explain it... I though watched the the progress bar and the blinking... (I think so, it is always a dead moment where I just look and watch/observe in great anticipation to see it succeed and then to use it.

Therefore, I think, the release number check could be different... on the other hand, the release number check for the notification should not have an impact on the flashing. I for sure cannot remember seeing the notice (may be it showed but it was on my - physical and mental - blind spot since I trust @Gordon announcement more that what my computer does... so I do with the header info in the response not to cache, which 'overwrites' (normally) the browser's settings...

wondered if I'd done something dumb (it's been known to happen)

Is that what I called (in message): '...having dud feelings towards myself'?

flashback "bug"

Like that term... because the bugs we are talking about here can - most of the time - be eliminated quite successfully. To bad with all the other kind of bugs it is not that easy... and the worst with the mental, PSTD related, flashbacks.

@Gordon and @DrAzzy, what about using odd version numbers for not released versions, such as 1v73, and even numbers for released versions, such as 1v74 - for versions to come?

I have read somewhere, that when a program is saved on Espruino and we flash a new version it will maybe not work, because there are many changes in the new version. Then reset(), save() and then flash.
By the way, I had the the unreleased on my Espruino, but nothing saved, so I could do the flash with no trouble.

Important point there bout reset(), save()... In my case, I had nothing saved. I uploaded after flashing. Updated initial post to be precise.