[DISCUSS] Define a release schedule for the project

[João Jandre Paraquetti <jo...@scclouds.com.br>]

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.

Re: [DISCUSS] Define a release schedule for the project

[Daan Hoogland <da...@gmail.com>]

nice to see this discussion being had again and sorry to be late in
replying João,

I see no replies have come forward yet. Let's add a new
https://github.com/apache/cloudstack/discussions/new/choose for this
as well. I still feel my proposal is good and should have been
applied. but we can gather all kinds of proposals in one place and get
to some kind of improvement someday.

One point of criticism on your proposal, though not a breaking point,
is that it doesn't guarantee backwards compatibility, something we
have always maintained so far (through upgrade paths). Not being
chained to old to technical debt is good, but it should not leave
people behind ;) We do have a hardly ever used procedure to deprecate
old plugins for instance. we should think about applying that to API
and other namings as well.

regards,

On Fri, Mar 15, 2024 at 12:10 PM João Jandre Paraquetti
<jo...@scclouds.com.br> wrote:
>
> 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.
>


-- 
Daan

Re: [DISCUSS] Define a release schedule for the project

[Daan Hoogland <da...@gmail.com>]

nice to see this discussion being had again and sorry to be late in
replying João,

I see no replies have come forward yet. Let's add a new
https://github.com/apache/cloudstack/discussions/new/choose for this
as well. I still feel my proposal is good and should have been
applied. but we can gather all kinds of proposals in one place and get
to some kind of improvement someday.

One point of criticism on your proposal, though not a breaking point,
is that it doesn't guarantee backwards compatibility, something we
have always maintained so far (through upgrade paths). Not being
chained to old to technical debt is good, but it should not leave
people behind ;) We do have a hardly ever used procedure to deprecate
old plugins for instance. we should think about applying that to API
and other namings as well.

regards,

On Fri, Mar 15, 2024 at 12:10 PM João Jandre Paraquetti
<jo...@scclouds.com.br> wrote:
>
> 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.
>


-- 
Daan