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

bump Cairo version to 2.7.0 #37

Merged
merged 13 commits into from
Aug 30, 2024
Merged

bump Cairo version to 2.7.0 #37

merged 13 commits into from
Aug 30, 2024

Conversation

javra
Copy link
Contributor

@javra javra commented Aug 23, 2024

No description provided.

@milancermak milancermak requested a review from tserg August 29, 2024 09:23
Copy link
Collaborator

@tserg tserg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just one small nit to bump the package version in preparation for release.

Scarb.toml Show resolved Hide resolved
Copy link
Collaborator

@tserg tserg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just came to my mind, should we set the edition to edition = "2024_07" here like in access control library too?

@javra
Copy link
Contributor Author

javra commented Aug 30, 2024

I think wadray should be independent of the edition, so we don't need to specify it. I'm also pretty sure that if it's just imported by another project, the compiler will use the edition of the importing package anyway.

@tserg
Copy link
Collaborator

tserg commented Aug 30, 2024

I think wadray should be independent of the edition, so we don't need to specify it. I'm also pretty sure that if it's just imported by another project, the compiler will use the edition of the importing package anyway.

Sounds ok to me, I will defer to @milancermak to take a final look before merging.

@milancermak
Copy link
Contributor

I'm also pretty sure that if it's just imported by another project, the compiler will use the edition of the importing package anyway

Wow, will it? TBH I'm have no idea how the editions work when importing, but this seems strange to me. I have the commit to update to 2024_07 edition ready locally, most of the updates there are about adding pub but also changes to import paths - some crates moved, some stuff became private and/or accessible via a simple into().

That's why it's strange to me that if this lib (which implicitly has edition 2023_01) would be imported into a 2024_07 project, it would not produce any errors. Do you know how that works? Does the compiler compile the dependencies separately using whatever is in their Scarb.toml?

Re: version change - I didn't want to do that just yet as I wanted to add a wad! and ray! macros to the library (and also do the 2024_07 edition 😬) and do a release only then.

@javra
Copy link
Contributor Author

javra commented Aug 30, 2024

That's why it's strange to me that if this lib (which implicitly has edition 2023_01) would be imported into a 2024_07 project, it would not produce any errors. Do you know how that works? Does the compiler compile the dependencies separately using whatever is in their Scarb.toml?

Just asked in the TG and apparently the compiler does compile each crate with its own edition, so I was wrong above.

@milancermak
Copy link
Contributor

Saw the discussion, thanks for checking!

Will unbump the version then, so I can sneak some more changes before 0.4.0 :)

@milancermak milancermak merged commit aa49dad into main Aug 30, 2024
1 check passed
@milancermak milancermak deleted the 2.7.0 branch August 30, 2024 09:59
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

Successfully merging this pull request may close these issues.

3 participants