Skip to content

Embark 0.8.4
Compare
Choose a tag to compare
@iurimatias iurimatias released this 04 Aug 12:35
· 6094 commits to master since this release
0.8.0
2128bac

New to Embark?

If you are new to Embark, see the Quick Guide or consult the wiki for a more complete documentation.

To Update to 0.8.4

npm update -g embark-framework

you'll need to add the "chains.json". run embark demo to see the differences.

In this release

This release of Embark allows you to develop, deploy and update advanced contract systems. It is much more advanced on how it manages and keeps track of deployed contracts. You can expect contract deployment to be now idempotent.

Actions after deployment

After a contract is deployed you can now specify actions to be done, for e.g to update an existing storage contract owner to the one you just released.

As example, the onDeploy field executes updateStorage with the new address of the MyDataSource contract.

development:
  DataSource:
    args:
  MyDataSource:
    args:
    instanceOf: DataSource
  Manager:
    stubs:
      - DataSource
    args:
      - $MyDataSource
    onDeploy:
      - Manager.updateStorage($MyDataSource)
      - MyDataSource.set(5)
staging:
production:

Stubs

If you contract interacts with another contract, you usually need to include a stub. You can specify this by adding the stub property. for example, the crowdsale example in ethereum.org would look like this

development:
  token:
    args:
      - 1000
  Crowdsale:
    stubs:
      - token
    args:
      - "0x123"
      - "100000000000000000000"
      - 30
      - "20000000000000000"
      - $token
staging:

Chain Manager & Persistent contracts

Embark now always keeps track of deployed contracts in each chain.

This means that you don't need to worry about contracts being unnecessarily redeployed, embark will only redeploy if absolutely necessary.

You can even refactor (up to a point) and so long core functionality remains unchanged the contract wouldn't redeploy. for e.g adding a new line, white space, or refactoring a local variable wouldn't cause embark to redeploy the contract, but renaming an external variable, adding/editing/removing methods will.

Another practical application of this is that contracts can be persistent. For instance, you can have a storage contract, that is never deployed, and a manager contract that gets often redeployed. This is quite powerful when used in conjunction with 'onDeploy'.

Misc improvements

Embark will now:

  • warn if gas costs are too low
  • warn if the contract deployment wasn't completely successful
  • retry on deployment fail

misc improvements were done on the example gruntfile. (remember you can use embark with anything, including meteor, not just grunt!)

Thanks

Special thanks to Tim Watts and Nikolai Mushegian for contributions to this release.

Assets 2
Loading