New release v3.0.0

[holgerd77]

No description provided.

[holgerd77]

Hmm, linting was passing on my local machine, strange. 😕 Travis is not making itself friends these days, grmbl.

[alcuadrado]

I'm slightly hesitant about releasing this version before it gets integrated into the vm. Otherwise, if a user installs ethereumjs-vm and ethereumjs-block (i.e. running npm i ethereumjs-vm ethereumjs-block) they'll get incompatible versions.

[alcuadrado]

Hmm, linting was passing on my local machine, strange. 😕 Travis is not making itself friends these days, grmbl.

I think you have an outdated package-lock.json

[holgerd77]

I'm slightly hesitant about releasing this version before it gets integrated into the vm. Otherwise, if a user installs ethereumjs-vm and ethereumjs-block (i.e. running npm i ethereumjs-vm ethereumjs-block) they'll get incompatible versions.

Hi Patricio, this comment is actually giving me some headaches.

Can we for now just stick to the a bit rough current procedure and just do the release in cases like this? We just don't have the capacity right now to switch to a more sophisticated model with doing beta releases all over the front and then synchronize releases at some point in time.

Actually we already had this situation reoccuring on various fronts (e.g. along with the major tx library update). As I said we can nevertheless improve on this by better document.

[holgerd77]

@alcuadrado Ok, was again the package-lock.json file, thanks for pointing this out! 😄

[alcuadrado]

I'm slightly hesitant about releasing this version before it gets integrated into the vm. Otherwise, if a user installs ethereumjs-vm and ethereumjs-block (i.e. running npm i ethereumjs-vm ethereumjs-block) they'll get incompatible versions.

Hi Patricio, this comment is actually giving me some headaches.

Can we for now just stick to the a bit rough current procedure and just do the release in cases like this? We just don't have the capacity right now to switch to a more sophisticated model with doing beta releases all over the front and then synchronize releases at some point in time.

Actually we already had this situation reoccuring on various fronts (e.g. along with the major tx library update). As I said we can nevertheless improve on this by better document.

Just for reference, this conversation is also happening here: ethereumjs/ethereumjs-monorepo#571

[s1na]

Hm, it seems we're in a situation. We need an ethereumjs-block release which includes #76 (and ideally a ethereumjs-blockchain release which includes this Block release) to have full Istanbul support in the VM. The main reason for this is the TX call data reduction.

On the other hand, I think rough consensus was to have Istanbul support in VM first as v4 and only then integrate this new ethereumjs-block which is promisified.

I guess the only option is to integrate the new Block in VM and release that as v5? What do you guys think? Alternatively we could also backport #76 to v2.2

[holgerd77]

@s1na Hmm, just had a look. Since this release would bring significant updates beneath just the TypeScript integration, e.g. also version updates on ethereumjs-common, ethereumjs-util, improved support/testing for newer Node versions, I wonder if it would be generally advisable to use this as a basis for an Istanbul VM. So I would cautiously support a v5 bump I think. But also a bit hesitant TBH. How difficult would an ethereumjs-blockchain update be? Do you have got an estimate on that?

[holgerd77]

@s1na On the other hand I am undecided though, since backporting #76 would be a very much simple fix. If this already does the thing maybe it is really the safer option for now. On writing this I have more and more the tendency to stick with that, seems there is already still enough to do on the VM without major dependency version updates and additional integration work.

[holgerd77]

@s1na Could you describe the technical steps needed for a backport release? I am bit unsure about this since I never practically executed such a case in the current branching model.

Would we branch off from the latest release commit and do these changes again? Hmm, maybe just give me a short step-by-step list please. 🙂

[s1na]

@holgerd77 Here's how I think we can handle the backport:

• Create a branch on top of the v2.2.0 tag
• Git cherry-pick the commits we want (or make other changes) on this branch
• Publish as v2.2.1

I can start by preparing the branch, but maybe we can wait before we do the release until we hear from @alcuadrado.

[alcuadrado]

I think I prefer the backporting alternative, as it would mean less integration work for the VM consumers. Having full Instanbul support in Ganache is pretty important, and this is the easiest path for them to achieve that. If we release all the pending breaking changes now, they may not have enough time to integrate them before the actual HF happens.

I think the steps proposed by @s1na would work.

[holgerd77]

@s1na @alcuadrado Ok, great, then we have a plan here. 🕵️‍♂️ 😄

[evertonfraga]

Closing in favor of ethereumjs/ethereumjs-monorepo#682.