Skip to content
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

Closed
fulldecent opened this issue Jul 24, 2021 · 25 comments
Closed

Release version 1.0.0 #11690

fulldecent opened this issue Jul 24, 2021 · 25 comments

Comments

@fulldecent
Copy link
Contributor

fulldecent commented Jul 24, 2021

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.

@axic
Copy link
Member

axic commented Jul 24, 2021

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.

@axic
Copy link
Member

axic commented Jul 24, 2021

To give two concrete reasons:

  1. the IR,
  2. standard library.

The IR
The IR (aka new codegen via Yul) is something we started to work on around 2017. The work is progressing much better this year and hopefully it can be released before 2022. We have already found a number of issues how the old codegen worked, and the IR works in these cases differently. This is basically a breaking change.

It would be foolish releasing 1.0.0 before the IR is released, is stable, and is the default.

Standard Library
The other major feature we work towards is the standard library, i.e. moving some of the features from the compiler into the language itself. This requires a number of improvements. Two name two: more capability of introspection; and more importantly, templates.

Again, it seems to be foolish releasing 1.0.0 before we have the standard library released.

Others
Besides these I could also name a number of features we think are important, but this is evolving. Lastly, there are major changes planned/coming to Mainnet. Think about "The Merge", data shards, the rollup roadmap or executable shards, etc. All these may require major changes to Solidity.

@fulldecent
Copy link
Contributor Author

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.

@axic
Copy link
Member

axic commented Jul 24, 2021

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.)

I do not think that is correct. The rules for semver at major=0 are different than major!=0:

  • a bump of minor means breaking release
  • a bump of patch means non-breaking release

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.

@fulldecent
Copy link
Contributor Author

SemVer item number 4:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org

@axic
Copy link
Member

axic commented Jul 24, 2021

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.

@fulldecent
Copy link
Contributor Author

fulldecent commented Jul 24, 2021

Benefits for current strategy:

  • Some people may think 1.0.0 includes some quality or completeness representation and we wish to make neither of these.
  • Users implicitly expect that old version have zero support. (Even though we explicitly tell them this too.)

Benefits for 1.0.0 today:

  • Downstream projects like Hardhat may support the latest version of Solidity every time right away (unless it is a new breaking release).
  • The semantics we wish to convey today (API stability for some releases) conforms to the SemVer (we currently advertise SemVer support but don't support).
  • It is no longer necessary for us to say "we support SemVer [some old version here]" or "we support SemVer with the exception that..."
  • It is possible for Solidity to make a "feature release" where some beneficial backwards-compatible change is introduced distinctly from a "patch release" that only fixes things.

Regarding ERC. I agree, a more succinct, documented, interoperable human- and machine- readable ABI representation is preferred.

@cameel
Copy link
Member

cameel commented Jul 24, 2021

  • Downstream projects like Hardhat may support the latest version of Solidity every time right away (unless it is a new breaking release).

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).

@fulldecent
Copy link
Contributor Author

fulldecent commented Jul 25, 2021

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.

@cameel
Copy link
Member

cameel commented Jul 25, 2021

Any project that understands Solidity to be following SerVer 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.

  • It is possible for Solidity to make a "feature release" where some beneficial backwards-compatible change is introduced distinctly from a "patch release" that only fixes things.

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.

@grepfruit19
Copy link

grepfruit19 commented Jul 25, 2021

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.

@fulldecent
Copy link
Contributor Author

fulldecent commented Jul 25, 2021

This issue, the proposal, and the pro-cons above are considering only the difference between:

  1. Continue doing exactly what we're doing now, and document/caveat that we are NOT following SerVer.
  2. Continue doing exactly what we're doing now, and release version 1.0.0 today.

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.

@axic
Copy link
Member

axic commented Jul 25, 2021

Changing our policy on supporting old versions (currently we don't) is not proposed here.

A 1.0.0 release implicitly provides the assumption of long term support. Especially when moving on from <1.0.0.

I understand that some project maintainers think that 1.0.0 means something special. It doesn't. Really.

To be honest, to me it seems you think it is special, hence proposing it? 😉

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.

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.

@fulldecent
Copy link
Contributor Author

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.

@axic
Copy link
Member

axic commented Jul 26, 2021

Only reflecting to this:

The language syntax AND the CLI syntax are the public API.

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:

  • Standard JSON I/O (the preferred interface)
  • ABI JSON
  • AST JSON
  • Metadata JSON
  • Metadata CBOR
  • Source mapping table
  • Linking table
  • the various other debugging outputs

@jwdonahue
Copy link

jwdonahue commented Aug 12, 2021

By definition, all prerelease versions, whether 0.y.z or -pre, are potentially breaking and this has always been the case with SemVer. Consumers must assume breaking and behave accordingly. Therefore, a publisher that perpetually publishes prereleases, cannot push a critical bug fix, because consumer automation will not take them without human intervention.

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.

@fulldecent
Copy link
Contributor Author

Here is one big specific problem:

https://hardhat.org/reference/solidity-support.html

Any 0.8.x version up to and including 0.8.9

We recommend against using Hardhat with newer, unsupported versions of Solidity. But if you need to do so; please read on.

When running an unsupported version of Solidity, our integration may not work or behave incorrectly.
This could mean that Solidity stack traces stop working, are incorrect, or incomplete. It could also mean that console.log stops working.


I want to get the point where EVERYBODY is using the latest version of Solidity.

@chriseth
Copy link
Contributor

chriseth commented Feb 9, 2022

@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.

@NunoFilipeSantos
Copy link
Contributor

Thank you for the wonderful read. 🤓
We're closing this issue for now as this issue has become stale.

@fulldecent
Copy link
Contributor Author

Hi @NunoFilipeSantos

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?

@fulldecent
Copy link
Contributor Author

Hoping for some support here from @cameel

@cameel
Copy link
Member

cameel commented Feb 15, 2024

Don't be ridiculous. It'll be out by 2040.

@fulldecent
Copy link
Contributor Author

Can we prioritize this and get it up to the 2039 release schedule?

@ts-web
Copy link

ts-web commented Aug 10, 2024

I'd like to add an anecdote that might help influence opinions on this.

When I see a library that has a 0.x. version, I think two things:

  • the library authors aren't very confident about it, or
  • the library is not ready for production

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 1.0.0.

There are only two reasons to not release 1.0.0: either the library authors are concerned that they might release a breaking change accidentally as a minor or patch, or they are uncertain about the scope of their library, so they can't tell whether a change will be breaking or not. These are the two reasons to stay in 0.x.

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 1.0.0 version). For competent consumers who have production applications, they'll typically lock the solidity version to a single version, because they know that bugs happen. Or if a consumer does use a semver range, the breaking change will affect them whether the version is 1.x or 0.x. In no case will it actually harm any consumer to adopt 1.0.0.

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 1.0.0 will help with this.

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, solidity@129.0.0 would be preferable to solidity@0.129.0, because it acknowledges that the library is not experimental, and it means the developers are tracking breaking changes precisely.

When you see a library with a large major version like 129, you think:

  • that library must have a large API surface area, or
  • that library frequently changes, and
  • they're really strictly adhering to semver.

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 1.0.0 now.

@fulldecent
Copy link
Contributor Author

This issue gets more relevant with time, not less. Requesting that this please be reopened.

@NunoFilipeSantos @axic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants