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

Support update_config.js migrations #2278

Closed
MaciejBaj opened this issue Aug 2, 2018 · 2 comments
Assignees
Labels
Milestone

Comments

@MaciejBaj
Copy link
Member

@MaciejBaj MaciejBaj commented Aug 2, 2018

Expected behavior

As the config.json is changing potentially in every release, update_config.js should be flexible and support the config.json migration between multiple versions.

To track the historical changes of config.json and be able to update from any to any of supported version the migrations of config.json needs to be introduced.

Actual behavior

update_config.js script is currently meant to update config.json from the previous to the newly released version.

Example

1.3.0 - current release
1.4.0 release removes broadcasts.releaseLimit key
1.5.0 release adds transactions.maxTxsPerMultisignatureQueue key
1.6.0 changes peers.accees.blackList key to peers.accees.whiteList key

Nodes might migrate:
1.3.0 -> 1.4.0,
1.3.0 -> 1.5.0,
1.3.0 -> 1.6.0,
1.4.0 -> 1.5.0,
1.4.0 -> 1.6.0,
1.5.0 -> 1.6.0.

With the current update_config.js form 6 separate files needs to be stored for each of pointed migration.
A flexible migration system will allow to apply the changes necessary for the particular update.

Which version(s) does this affect? (Environment, OS, etc...)

>= 1.0.0

@MaciejBaj MaciejBaj added this to New Issues in Version 1.2.0 via automation Aug 2, 2018
@MaciejBaj MaciejBaj added this to the Version 1.2.0 milestone Aug 2, 2018
@MaciejBaj MaciejBaj assigned nazarhussain and unassigned ManuGowda Aug 2, 2018
@nazarhussain

This comment has been minimized.

Copy link
Contributor

@nazarhussain nazarhussain commented Aug 2, 2018

@MaciejBaj This will be nice to have if we plan to keep multiple releases supported on network. If you foresee that's gonna happen then we can work on this issue. Otherwise supported migration of one prior release is good enough.

@MaciejBaj

This comment has been minimized.

Copy link
Member Author

@MaciejBaj MaciejBaj commented Aug 3, 2018

Yes, as currently, we are working on two Minor Releases (1.2.0 and 1.1.0) the problem will be present as soon as 1.2.0 will be released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Version 1.2.0
  
Closed Issues
3 participants
You can’t perform that action at this time.