Closed mmv08 closed 8 months ago
Going with the second approach:
To do
Safe repositories that need to be updated for future releases:
Other potential other sources on Github that need to be updated for future releases: https://github.com/search?q=%40safe-global%2Fsafe-contracts&type=code&ref=advsearch
Regarding:
Can we notify the SDK team in Slack about this?
Create npm release of 1.4.1, 1.3.0 builds?
Not required by SDK team. We will consider deploying old version if required.
What does "easier discoverability" mean? Repos are not "app stores" where you look for the coolest name. Not sure what is requiring such a change, but I think it is useless and would just burden developers who would think - there is no new release where in reality the code lives under a new package name.
It's the same situation with @gnosis.pm/safe-contracts. There are projects that use those and never update to @safe-global/safe-contracts.
I hope that you've realy thought out that well.
Repos are not "app stores" where you look for the coolest name.
Yes, but at the same time, names should be descriptive. What does safe-contracts mean? Is it the safe{core} protocol? Are they safe token contracts? Is it the vesting contract? Is it modules? We grew past the stage where safe-contracts could only mean the account contracts.
It's the same situation with @gnosis.pm/safe-contracts. There are projects that use those and never update to @safe-global/safe-contracts.
They should pay more attention to the output when installing dependencies then. Usually, there's a message if the package has migrated to a new one.
I do not buy the argument because the existing tools allow us to perform the migration smoothly with aliases, warnings and stuff.
To better highlight the contents of the repository and enable easier discoverability, we'd like to rename the repo to
safe-smart-account
There are two approaches: