Lisk-sdk: Change of direction regarding 1.0.0 release

[LucasIsasmendi]

After an in depth core meeting, we have decided that we won't include the Accounts ledger redesign #544 and transaction pool rewrite #561 in the 1.0.0 release.

With this decision the new accounts ledger and transaction pool integration #972 issue will be closed. Furthermore, the rounds logic rewrite https://github.com/LiskHQ/lisk/pull/597 that was done in support of this will be reverted.

The motivation for this change is to:

• Finish 1.0.0 and achieve our objectives as originally planned but without any significant redesign of the schema, or large movements of behavior to the database layer. We have decided to keep all behavioral parts contained within the application layer where it is the easiest to mutate to and verify change, and therefore maintain.

The current 1.0.0 project will be completed by achieving the following:

• [x] Revert the rounds logic rewrite https://github.com/LiskHQ/lisk/pull/597 and related PRs #1174
• [x] Add unit test coverage for rounds logic #1187
• [x] Add unit test coverage for rounds module #1300
• [x] Add functional test coverage for rounds system #1303
• [x] Add unit test coverage of account logic #1186
• [x] Decouple SQL generation from account logic #1175
• [x] Port fork rewind 5-3 fix from 0.9.10 to 1.0.0 #1208
• [x] Review unit test coverage of blocks modules #1301
• [x] Review unit test coverage of logic #1302
• [x] Achieve atomic block save #302
• [x] Achieve atomic block deletion https://github.com/LiskHQ/lisk/issues/1563

NOTE: As originally intended here: https://github.com/LiskHQ/lisk/issues/302 in October, 2016!

By completing issue #302 it will help us achieve our objective of saving blocks, transactions and rounds atomically. It will build on the foundations we have already in place for 1.0.0.

[pcdinh]

Hi Lucas,

What do you mean by "closed"? If they are decided to be important to implement for several months, why don't you delay them to 1.1.0?

[karmacoma]

@pcdinh We have expanded on the reasoning in the issue description. There has been a change of plans in order to deliver 1.0.0 sooner rather than later, but with the same objectives achieved.

In short, the objective of achieving fully atomic block writes and thus greater block processing efficiency through the application layer, has now been put back into focus.

[pcdinh]

@karmacoma

Hi Oliver,

As a developer, I understand that "closed" mean "stopping working on that. The task is abandoned". However, lots of tasks have been working on since April. Huge amount of code has been written. If we "close" it, we will effectively abandon lots of done work.

In my projects, if there is no pivot or omission of no-longer-relevant features, I will move those tasks to backlog and re-scope the release plan.

I am not sure if I understand your plan here.

Thanks,

Dinh

[SimonDeSchutter]

Hi Oliver,

I have the same question as @pcdinh.
Are you just reverting the codebase and discarding all work done in those tasks?
If yes... Why don't you just push those tasks back to be included in a later release?

Kind regards,

Simon

[karmacoma]

@pcdinh @SimonDeSchutter All work done thus far towards the 1.0.0 branch is largely unaffected.

Here the change of direction revolves around the following #597, #983, #989, which we have decided to not proceed with, as the bleeding of behavior across the application and persistence layer is not something we need or want architecturally. NOTE: #983, #989 were merged with this in mind into #972, separately from 1.0.0.

Some of the changes being reverted may be introduced iteratively, as we move back to a more frequent release cycle. Therefore, yes we are pushing back some work for later release. In the meantime we focus on delivering what was originally planned. Then we move forward past 1.0.0.

[SimonDeSchutter]

@karmacoma

Ok, that clarifies a lot! Thanks for the info.