Hi all,
I had posted this message on another thread, but following Rohit's
advice I've decided to create a new one for it. That being said, I have
another proposal for the versioning scheme. Instead of dropping the "X"
on our X.Y.Z.N, we can set a fixed schedule (that can be further
discussed) for the version changes:
- Every two years, we release a major version (X), which can contain
changes that break backward compatibility, such as (but not limited to):
removing unused/useless APIs, renaming APIs, and changing the default
behavior of features. These changes must be discussed with the devs and
be properly communicated to the community (via API deprecation, for
example) at least one minor version before the major release;
- Every semester, we release a minor version (Y) of the current major
(X) version, these can contain new features/APIs, as long as the
backward compatibility is maintained; also, feature/API deprecation
should happen on these versions;
- Every 2/3 months, we release patch versions (Z), that fix any bugs
that were released with the major and minor versions, these versions
should not contain any new features;
- In extreme cases (such as with security issues) we work on and release
security versions (N);
The proposed schedule is only a sketch that can be worked on. However I
believe that the project can benefit from:
1. A fixed release schedule;
2. A mechanism to introduce disruptive changes, so that the project can
evolve and not be chained to the same features/API/limitation/technical
debts forever.
Furthermore, having a schedule allows us to have a project roadmap, that
outlines the future deprecations, changes and big features.
Best Regards,
João Jandre.
