Hi Rene,
Thank you for your input!
I mostly agree with your points on when DB/API changes may be made.
Also, we currently do not have a Alpha/Beta/Stable scheme for APIs as
far as I know, but it could be an interesting addition to the process.
I have added my latest explanation and points re
Hi, Rohit
In your previous message in this thread you proposed a hold on the vote.
In my reply I said that it would be closed since there was more
discussion to be made according to you. And now you are voting in the
same thread?
Can we continue the discussion on the discussion thread or is
Hello Rohit, and dev community,
I'm sorry, but I do not understand your (Rohit) position. I have stated
the reasons for my proposals and I have been waiting for the feedback of
the community (including yours).
Since it seems like you did not fully understand my proposals, I will
try to make
Should there be nuances on the DB and API changes to help the
conversation? A few thoughts:
- DB changes to add new required fields or tables can only be made in a
major release.
- DB changes to add new “optional” tables, new optional fields, new
required fields with defaults, and new views allow
-1 (binding)
This is mainly due to the point that "Changes to the database schema should be
introduced only in major versions" — the definition of "major" here (4.xx,
5.xx) is based on Joao’s interpretation, and the proposed versioning approach
isn’t well defined and is asked for a vote.
Addit
