-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Release version 1.0.0 #11690
Comments
We are indeed making breaking releases (and many major features we want are still not implemented). Just remember both 0.7.x and 0.8.x came out in 2020/2021, and we plan 0.9.x this year. Going to 1.0.0, while still following semver, would mean we'd need to release 2.0.0 for a breaking release. |
To give two concrete reasons:
The IR It would be foolish releasing 1.0.0 before the IR is released, is stable, and is the default. Standard Library Again, it seems to be foolish releasing 1.0.0 before we have the standard library released. Others |
There is no shame in "not getting everything done for 1.0". There is already a significant amount of value. Solidity is deployed and protecting contracts with more value than 100 country's GDP. And also there's no shame in "we are bumping the major version because of Yul, or StdLib, or even some very minor incompatible change". And no shame in bumping major versions, even if 20 or more major versions in a year. Please note that today, every release of Solidity (<1.0.0) is advertised as a breaking change that no nobody should use until they reread all the documentation. (This is what SemVer means.) But once 1.0.0 is released, some versions can be advertised as non-breaking changes. There is a lot of value to be had from this. |
I do not think that is correct. The rules for semver at major=0 are different than major!=0:
This means for example all the 0.8.x releases are non-breaking, but 0.8.0 was breaking from the 0.7.x series. |
SemVer item number 4:
|
It seems it does read like that today. However I am pretty sure at some point it read as I explained, as that is the rule we have been following since we adopted semver. And if you look at the Solidity changelog, it reassures that we have been following what I explained strictly. I thought this has been common knowledge by the users of Solidity? It is really late here (and is a weekend), so I will not spend time looking at archive.org or GitHub issues to prove this. If you allow me a comment: I do not think ERCs should be defined in terms of a Solidity snippet or interface. The interface on Ethereum is the ABI, and not Solidity. Choosing to describe standards using Solidity may not be the best practice, as it excludes those using other languages, or even the possibility for such languages to emerge. Lastly I'd appreciate if you could list pros/cons for both the current scheme vs. the 1.0.0 today. |
Benefits for current strategy:
Benefits for 1.0.0 today:
Regarding ERC. I agree, a more succinct, documented, interoperable human- and machine- readable ABI representation is preferred. |
Does Hardhat really only support 0.8.4 and not 0.8.6 because of the number? 0.8.6 is still backwards-compatible down to 0.8.0. Just like all the 0.7.x releases are backwards compatible with 0.7.0 and so on. Would they support that version if it was called 1.6.0 instad of 0.8.6? I thought it had more to do with them being cautious and wanting a new version to be thoroughly tested before they officially bless it as a supported one. Also, the particular case of 0.8.4 might have something to do with the "unreachable code" warning in 0.8.5 (#11522) and people wanting to skip that particular version (it's already fixed in 0.8.6 though). |
I do not speak for the Hardhat project. But according to their error/warning messages, they only support specific (old) versions of Solidity rather than blocklisting known-bad versions. Allowing a package to distinguish backwards-incompatible, feature and fix releases is exactly the problem SemVer is designed to solve. Any project that expects Solidity to follow SerVer today is wise to NOT support the latest version until manual review. |
You have a point here. If we're not following SemVer then I think we should clearly document what our backwards-compatibility guarantees are (regardless of whether SemVer convention changed or it was just misinterpretation on our part). The various places where it's described (Intro, Version Pragma, Version String) only refer to SemVer instead of stating that outright.
But do patch releases even make sense before the project is mature enough to have proper major releases that are supported long-term? The change in versioning would enable us to make patch releases for older compiler versions but we're still at 0.x.y precisely because we do not yet think it's a good moment to start maintaining older releases long term. I think that releasing 1.0.0 might introduce an expectation that at least some fixes will be backported. Also, with the current release frequency each release is always a mix of new features and bugfixes. Even 0.8.6 which was basically a bugfix release for 0.8.5 included a small feature. More frequent releases are not necessarily a good thing. Neither for us nor for users. We do not make them lightly so each one takes some time and effort on our part. It would also dramatically increase the number of compiler binaries we have to keep around. We have to keep providing all officially released binaries indefinitely to enable contract source verification. |
The bump from 0.x to 1.0 would suggest to me, and I'd imagine many other developers, that something significant has changed. I think breaking from the schema that's being used currently, even if it's perhaps "incorrect" right now, would introduce more confusion than clearing anything up. |
This issue, the proposal, and the pro-cons above are considering only the difference between:
Changing our policy on supporting old versions (currently we don't) is not proposed here. I recommend that we consider and implement the industry standard SemVer, which we already recognize as best practice. I understand that some project maintainers think that 1.0.0 means something special. It doesn't. Really. Other projects like Inscape we waited 17 years to make our first 1.x release and nothing was gained. It never achieved the magic "100% compliance of SVG standard" which was our goal there. They also do not support old versions. And the world kept spinning. Other than the public awareness of Solidity reaching 1.x will cause, and I can guarantee this will be the front page of world newspapers for no more than 7 days straight, there will be little public expectations on the project. I can guarantee there will not be this much discussion about moving from version 1.x.y to 2.0.0. But SemVer tells us "Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes". I hope we can agree that Solidity ALREADY has a public API. People depend on it ALREADY. Its deployments control assets worth more than all but 10 of the companies on the S&P 500 list. The time when you have defined a public API (i.e. any possibility that a future release may continue to support any feature you have already made available), that is the time to release version 1.0.0. |
A 1.0.0 release implicitly provides the assumption of long term support. Especially when moving on from <1.0.0.
To be honest, to me it seems you think it is special, hence proposing it? 😉
Which one is the public API? The language syntax? The various compiler interfaces? These are questions we need to answer at every single change we make. I really think what we need to do is improve the documentation to make it more visible what process we follow. |
The language syntax AND the CLI syntax are the public API. SemVer gives us this advice: How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0. |
Only reflecting to this:
There are many more interfaces of the compiler outside of the CLI, and the CLI is not even the preferred interface to the compiler. To name a few:
|
By definition, all prerelease versions, whether If you are good at predicting when you have a non-breaking change to publish, then by all means, please use the full X.y.z, where X > 0, non-prerelease version format. Then you can experiment with follow-on prereleases, but reserve the ability to release critical patches. Do not hide behind prerelease publications, simply to avoid regularly increasing major version numbers. That attitude is expected from the marketing department, not engineering. But, if you are not certain you can attain the full intended target feature set without major breakage, and you don't want your customers taking dependencies on your product prior to feature completeness, then by all means, continue on your prerelease track. Just keep in mind, that most products; really aren't ever feature complete, until some time after they are nearly obsolete. If you have a large user base that is committed to using your product, you're probably better off in the long haul, if you start cutting releases on a regular basis, even if they are frequently breaking changes. Even if you have no intention of ever going back and releasing a non-breaking fix for an earlier version, you will have at least reserved that capability, should you ever change your mind. Releasing X.y.z, where X > 0, does not imply anything at all wrt quality or commitment. It just lays the baseline for future versions to employ the full semantics that SemVer specifies, should you decide that you need them. |
Here is one big specific problem: https://hardhat.org/reference/solidity-support.html
I want to get the point where EVERYBODY is using the latest version of Solidity. |
@fulldecent I'm not sure how this relates to the versioning, but the problem is that some features of hardhat are using pattern-matching on the bytecode. Essentially they are using a non-public interface. Most of these pattern-matching techniques can nowadays be solved differently, though. |
Thank you for the wonderful read. 🤓 |
it is now the year 2050. This project has been alive for decades. Can we please start thinking about locking down version 1 of this product? |
Hoping for some support here from @cameel |
Don't be ridiculous. It'll be out by 2040. |
Can we prioritize this and get it up to the 2039 release schedule? |
I'd like to add an anecdote that might help influence opinions on this. When I see a library that has a
In this case, de facto, solidity is being used in production, and I assume this was intentional --- that at some point there was an announcement that "solidity is ready to use", or "we're releasing solidity". At that time the version should have been promoted to There are only two reasons to not release About bugs --- mistakes will always happen, but they might happen less if the library is presented as a non-experimental or stable library in the first place (with a About unknown library scope --- if the library authors don't know the scope of their library, that's not really acceptable, and steps should be taken to try to understand the library scope. Mindset is a crucial component to this. The library must be regarded as serious and important --- breaking changes must be identified properly. Contributors will feel a stronger need to ask questions like "how does this change affect consumers", and "is this a breaking change?" Adopting If the reason is that "we don't want to release 1.0.0 because then we'd have to release 2.0.0, then 3.0.0, etc., when we make breaking changes" --- that's close to sentimental versioning which is an antipattern. Consumers don't want "nice" versions or low versions; they want rigid accuracy and certainty. If solidity gets 129 major version bumps, even then, When you see a library with a large major version like
It does not give the impression of: "wow they must be making many mistakes", because amateur developers tend to not properly identify or count their breaking changes. So their libraries stay in the low numbers. So a high major version is seen as a good thing. At the very least, it's accurate. If the reason is "we don't want a high major version number because it makes solidity seem unstable", then realize that masking the instability does not make it stable; it just hides the fact that it's unstable. In conclusion: solidity is a serious library, and as such, it should be promoted to version |
This issue gets more relevant with time, not less. Requesting that this please be reopened. |
This is a project management issue.
Not a milestone issue to track a bunch of features that are needed for version 1.
Let's release version 1 today.
The same exact code as the latest release. Just renamed as version 1.0.0. Or take the next release that would have been 0.x.y and call that 1.0.0.
It's time.
We are not breaking things every release.
There are many contracts deployed already, responsible for hundreds of billions of USD worth of things.
Core developers here are responsible and deliver quality releases reliably. The community is engaged. They are accessible and available at public events. When they aren't at public events, people ask how they are doing. Thank you.
This is what a >= 1.0.0 project feels like.
There is no risk.
Currently when experimental or breaking features are introduced they are kept behind experimental flags or they are documented.
When new versions of Solidity are released, all support for old versions is dropped. As a general rule, only the latest release gets security updates.
Releasing version 1.0.0 does not change any of this.
There is a huge benefit.
When people release a library or some other code, they want to say "this works on Solidity x.y.z and anything later that is compatible". This is much easier after you release 1.0.0 because you can use Semantic Versioning to compare compatible versions. (This fails for < 1.0.0.)
Two specific problems are: people are hardcoding 0.8.0 version. People should not be required to hardcode Solidity versions to guarantee stability. Another example is Hardhat, it looks great but it doesn't support the latest version of Solidity and produces a warning. Hardhat developers should not need to do anything when a new compatible version of Solidity is released. We definitely don't want tools telling contract developers not to use the latest version of Solidity.
So again, thank you to everyone here. We did it! This software is amazing. We love you and your work. Let us allow official guarantees of feature stability by releasing 1.0.0 today.
The text was updated successfully, but these errors were encountered: