Skip to content

v0.10.1 broke AST API #1331

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

Closed
willemneal opened this issue Jun 12, 2020 · 6 comments
Closed

v0.10.1 broke AST API #1331

willemneal opened this issue Jun 12, 2020 · 6 comments

Comments

@willemneal
Copy link
Contributor

In the release IndexSignatureDeclaration is removed from the AST, which breaks code that depends on it.

While this is a fine change to make it should be done on a major release, which I also am not opposed to seeing more of. Before 1.0 users can expect changes and honestly major releases signal progress toward stabilization.

So I suggest we use a tag in any commit that causes a breaking change to the API and not allow it to be included in a minor release.

@MaxGraey
Copy link
Member

I guess it just renamed from IndexSignatureDeclaration to IndexSignatureNode

@jtenner
Copy link
Contributor

jtenner commented Jun 12, 2020

I had an API broken too in as-pect. Currently new installs with latest aspect are broken.

@dcodeIO
Copy link
Member

dcodeIO commented Jun 12, 2020

The offending PR is #1283, where I noted

Technically this is a breaking change for internal compiler API users due to changed parameter orders and similar, but not for compiler users, so I'm not sure if we should make this a new major release just for that, or if it's ok to assume that internal API compatibility is something we can't guarantee between minor versions just yet?

Perhaps we can continue thinking about this here?

A radical way to deal with this would be to switch to conventional commits / semantic releases, and stop 'thinking' about version numbers entirely.

@willemneal
Copy link
Contributor Author

Yeah it would be nice to separate the two, but I think the solution is to just not fear increasing the major version. I don't see a tiny breaking change increasing the major version as a bad thing when you are pre 1.0.

@jtenner
Copy link
Contributor

jtenner commented Jun 12, 2020

Technically this is a breaking change for internal compiler API users...

I only want to point out that the users you describe here are people who use as-pect.

One last thing if it wasn't super clear: I want to thank you personally for making AssemblyScript awesome, and I am not afraid of breaking changes. When I sat down to create the first version of as-pect, I knew that I would have to constantly change and refactor my software for the next few years to make it functional.

With all that said, I just wasn't expecting things to break in the way they did.

My suggestion is to just make whatever changes need to be made to make it better and start increasing the version number with semantic releases as described.

@MaxGraey
Copy link
Member

I guess we could close this since we have semantic release

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

4 participants