Details

    • Project
    • Resolution: Incomplete
    • Minor
    • None
    • None
    • library
    • None
    • 0

    Description

      Holy Moly !

      To turn this SDK from hm ok into holy moly! we need some breaking changes and therefore a new major version.
      Some technical decisions in the SDK are not culturally aligned with its user base, the Node.js developers.
      They also create bugs, unexpected and potentially harmful behaviours or simply unexpected limitations that are detrimental to the developer's experience.

      The DX is one of the main make or break with businesses, because it is the developers that are evaluating the solution, and their attention will eventually be on the SDK.

      Before anything, I want to let you know that I am willing to write this v5 myself.
      By writing my PR on type safety for KV operations I have accumulated a great knowledge about the lib and how it works. However I will need some support to valid some Couchbase behaviour beyond what I can test myself locally.

      Regardless of who does what, I would like to start the discussion on the v5 of the SDK.
      Here is my usual process :

      Proposed Process

      1. The Dream

      We describe what would be our ideal SDK, regardless of the technicalities, priorities or costs.
      Once we agree on the Dream, we can move on to the next step.

      2. The Goal

      We decide what we will actually aim to do.
      The selection is based on technicalities, customer needs and business priorities (such as give more importance to some aspect because money is there, or legal commitments).

      We typically exclude features that have a poor value/cost ratio and the one that would create too much maintenance.

      Because this project will be put in the hands of developers, the customer is not only the company that uses Couchbase, but mostly the developer using the SDK.
      For this very reason, some implementation details can be included in the project requirements.

      3. The Deliverables

      Now we know what we want to do, we need to decide how we will ship it. Typical questions we need to answer are :

      Do we ship everything at once or do we split the project into multiple deliverables ?
      We are the rules to split the project ?
      In what order do we ship the deliverables and requirements ?

      4. The Project

      This part is about how do we, in practice deliver this new version. 

      Since it's a new version, we should think of the migration from v4 to v5.
      With what I have in mind, the migration will be easy and impact few customers but we still want to do things according the state of the art : deprecation notices, migration interfaces, documentation and faq.

      Do you already have a way to collaborate on documents or do I create a Google Doc ?

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            priya.rajagopal Priya Rajagopal
            JesusTheHun Jonathan MASSUCHETTI
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty