Summary: Increase the "beta/RC" window for 1.4 by one to two releases to the left to facilitate testing a large scale change

Background

We have a fairly large scale change under review (besu#215) that is taking our internal BytesValue values that wrap byte arrays and replacing it with an crypto focused Apache library that does the same handling.  This is a very large (10K+) change and very far reaching.

  1. One maintainer raised the point that with such a large change how are we sure that the test cover everything and are stable and performant?
    In addition to existing unit tests, integration tests, acceptance tests, and reference tests we may want to spend more time just running nodes.

  2. This change also opens up the possibility of adding rich byte handling to our plugins API instead of simply passing byte arrays.
    1. This cannot be done in a bi-weekly release because it is a breaking change
    2. We need to co-ordinate with the authors of all the plugin APIs to validate if this change is good for the particular plugin
    3. This may reduce friction between the plugins API and the core of Besu 


Proposals:

  • Beta Releases
    • Stop releasing 1.3 releases in December (1.3.7) except for important bug fixes
      • a new 1.3 branch is made if we need fixes
    • Release two 1.4-beta releases in January,
      • this takes over the "master" branch
    • Release the RC in early February (current schedule)
    • Release the 1.4 in late February (current schedule).
    • Ship the Tuweni PR as the first commit after we stop 1.3 support
    • Including Plugin API changes
  • Longer RC Cycle
    • Stop releasing 1.3 releases after first January release (1.3.8) except for important bug fixes
      • a new 1.3 branch is made if we need fixes
    • Release 1.4 RC in mid January (2 weeks earlier)
    • Release more RCs as warranted
    • Release the 1.4 in late February (current schedule).
    • Ship the Tuweni PR as the first commit after we stop 1.3 support
    • Including Plugin API changes
  • Status Quo
    • No schedule changes
    • Ship the Tuweni PR when it is ready with all others in a bi-weekly release
    • Maybe do plugin API changes as part of the 1.4 release

The down side of the status quo approach is that it provides a very limited window to co-ordinate the use of the plugin APIs by downstream consumers, about 2 weeks or less.  By going with one of the longer cycles there is more co-ordinating time.  Going with a "beta" release would imply that things may change in response to testing.  However going with a longer RC window reduces the amount of time we are off of bi-weekly agile releases.

  • No labels

6 Comments

  1. Nicolas MASSART

    I agree with point 1 about running nodes on a longer timeframe, I'm a bit less enthusiastic about taking advantage of a longer RC to add more things or it's just that I don't really see how a longer RC enables more features. To me it doesn't change the length of the dev part, just the RC live test is longer. Or is it because it means that while the longer RC runs we have more time to develop for the next release?

  2. Adrian Sutton

    I like the beta release option. Gives plenty of time for plugin users to adapt to the API changes and most likely avoids the need to maintain a separate branch (we may need a 1.3 branch for an emergency fix but it still won't be long between stable releases so unlikely to be required).

    Given how useful a decent bytes library is vs just using `byte[]` and that Tuweni bytes is already a stable API I think it makes sense to expose that in the plugin API.

  3. Christopher Hare

    Updating the PluginAPIs to leverage the Tuweni library sounds like a good idea, as it could result in cleaner and potentially more performant code.


    Although I’m curious what the term `important bug fixes` entails and how long the 1.3 branch would need to be maintained?
    (i.e. who decides what an important bug is and the length of time that fixes will be ported across from master)

    1. Edward Evans

      I think we consider the 1.3 release series to be "under maintenance" until we have our first 1.4 release.

      In terms of "important bug fixes", I think we will know them when we see them, and can be discussed on a bug-by-bug basis.

      1. Christopher Hare

        1.3 release series to be "under maintenance" until we have our first 1.4 release.

        That sounds reasonable. A predetermined cut-off point should help avoid any uncertainty around continual support and potential user expectations for it (i.e. 1.3 being a long lived supported release/branch).

    2. Danno Ferrin

      One example of an important bug fix is something with a CVE number.  In general the answer to the question of "can it wait a month" should be some form of "no."  But like Ed says, we will only know for sure when we see them.