On Feb 3, 2014, at 10:04 PM, Jason Manley wrote: > I use this function quite a lot, actually. Thanks Dave!
I'm glad it's being useful! > But just a note that it doesn't set mask parameters correctly if the > top-level mask has changed (obviously, because it can't map the parameters > correctly). So it's not a one-stop fix-all solution in every case, but it > sure saves a lot of time in most cases. Yeah, here's a synopsis of what happens. The update_casper_block function copies common mask parameters from the old block to the new block. It discards mask parameters from the old version of the block that no longer exist in the new version and it leaves at the default value any parameter of new block that did not exists in the old block. I think this is the only sensible thing the update_casper_block function can do when mask parameters are added or deleted. Block developers/maintainers would help the block users if they give new parameters default values that are as backwards compatible as possible with the old version of the block. Obviously not everything case can be handled automatically, but this can help to minimize the need for manual intervention. Hopefully any changes to a block that require manual intervention are well documented (ideally on the wiki, but at least in the got commit logs). If the mask and/or mask init script of a block changes dramatically, it might be a good idea to include/update a hidden block_version parameter so that the "same state" optimization will know that the mask init script needs to be run again. Dave
