Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

Change of direction regarding 1.0.0 release #1169

Closed
11 tasks done
LucasIsasmendi opened this issue Dec 20, 2017 · 6 comments
Closed
11 tasks done

Change of direction regarding 1.0.0 release #1169

LucasIsasmendi opened this issue Dec 20, 2017 · 6 comments

Comments

@LucasIsasmendi
Copy link
Contributor

LucasIsasmendi commented Dec 20, 2017

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 #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:

NOTE: As originally intended here: #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
Copy link

pcdinh commented Dec 20, 2017

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 karmacoma changed the title Change directions regarding 1.0.0 release Change of direction regarding 1.0.0 release Dec 20, 2017
@karmacoma
Copy link
Contributor

karmacoma commented Dec 20, 2017

@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
Copy link

pcdinh commented Dec 21, 2017

@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

@Archethect
Copy link

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
Copy link
Contributor

@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.

@Archethect
Copy link

@karmacoma

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants