Latest 4 solc versions are missed.

[Latrasis]

When listing the remote versions the loop misses the last 4 versions in the list.

for (var i = sources.length - 1; i >= 0; i--) {
    // FIXME: use build as well
    var version = sources[i].match(/^soljson-v([0-9.]*)-.*.js$/);

    // Skip invalid lines
    if (!version) {
      continue;
    }

    if (version[1] === wanted) {
      downloadBinary(sources[i].match(/^soljson-(.*).js$/)[1]);
      return;
    }
  }

[axic]

@Latrasis as an improvement it would be nice to improve solc-bin by having the versions in a JSON file.

solc-bin contains list.txt and list.js for the versions. The latter has two fields: versions (equals to list.txt) and releases (which is the first build of each version).

Do you think you could improve the process in solc-bin? That could help solc-js :)

[Latrasis]

@axic: Sure thing! Just to understand a bit more, what is the process of adding a new version? Is the list.txt appended to? Or is it generated?

[axic]

@Latrasis both are generated by this script

[chriseth]

Can you please explain a bit more why you think this is a bug?

[Latrasis]

@chriseth:
The very reason I stumbled upon this was when the latest version3.2 got an update on soljson-v0.3.2-2016-05-06-9e36bdd.js which allowed inlined library contracts: ethereum/solidity#493.
(It seems like it should have been 3.3 from my option, but I digress)

While the realtime solidity compiler (RSC) fetches the latest version, with the current issue beforehand solc-js does not. Which meant that any contract that would compile on RSC, would not compile on truffle or other tools. This produces confusion that RSC and solc-js would have conflicting latest versions.

[chriseth]

Ok, thanks, now I understand. The "inline library functions" feature is not yet released. It is part of the nightly developer snapshots that are used by browser-solidity. Version 0.3.3 will be released as soon as solidity is stable enough and it will of course contain this new feature.

The npm version is created for releases only in order to prevent people from deploying contracts with non-release versions (which are less stable and harder to verify because they might not be as well archived as the released versions).

Using loadRemoteVersion('latest'), you can always get the latest version just as browser-solidity does, but I think it is not a good idea to release a new npm version with every development snapshot.

The reason why browser-solidity uses development snapshots is because it is trivial to switch back to an older version if something goes wrong.

[axic]

@chriseth if this versioning/build behaviour is not explained in the documentation (readthedocs), it should be. cc @Denton-L

[Denton-L]

Sorry, I'm not too familiar with web development. Just to make sure I'm updating the documentation correctly, if I wanted to use the latest development snapshot, I'd do the following?

var solc = require('solc');
var snapshot = solc.loadRemoteVersion('latest');

[axic]

@Denton-L thank you! Answered your question on the PR.

[Latrasis]

@chriseth I see, I missed that. But as a suggestion: how about using stable, and nightly version labels instead? This would be more semantic than simply using latest with can be ambiguous, and is a common used practice that has proved itself within many projects.

[chriseth]

@Latrasis yes, good idea!