-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
handle pragmas in provided sourcecode #75
Comments
Sounds like the wrong solution to a perceived problem. |
As in the node we can publish incompatible apis at new pathes, like:
then we will be able to migrate smoothly to a new version of compiler, and maintain old versions of compiler if necessary. Also it can replace https://latest.compiler.aepps.com/ |
if it's only about major releases we can just deploy and host these different versions of the compiler. I think that's already being addressed if I remember correctly. @davidyuk in case we have specific URLs for each major compiler release we should be fine on that side, right? then we could close this issue here |
It would be a major change if one instance of the HTTP-compiler should include multiple versions of the compiler. It wouldn't be impossible, but it doesn't seem like the right way to do it?! |
the URL should include compiler version ('v5', 'v6' instead of 'latest' and so) but still, the user needs to select the proper compiler by himself or SDK may start to parse pragmas against the list of provided compiler versions. If we need this feature, the most user-friendly would be to do it on the compiler side though it will increase the cost of compiler maintenance. One more use-case when the support of multiple compiler versions can help is bytecode validation: if we want to validate a contract compiled by an old version (that is on-chain now and still can be called), won't the latest compiler reject it? |
see: aeternity/aepp-sdk-js#1189 (comment)
this still needs some discussion.
The text was updated successfully, but these errors were encountered: