Sorry for being late to the party. I think what Kirti proposes would be good
for the project and end-users. As mentioned, we could start with 2-3 releases
per year, and once we improve on the process and automation (CI/CD) we could
reevaluate.
Thanks Ayush, Thanks Stamatis for your valuable inputs.
Let us a give a try to get at least 2 releases/year so that we can evaluate
further on strategy plan of release activity. I see another mail thread for
interested devs who can volunteer as Release Managers for next subsequent
releases
Hello,
I am not sure what a branch cut actually refers to. As I mentioned in the
past I am not in favor of maintaining multiple release branches; the cost
is high and the number of volunteers is simply not enough. I am willing to
reconsider if things change in the near future.
Apart from that,
Hi Kirti,
Thanx for the initiative. This sounds very interesting, but I doubt if it
is that easy to incorporate. Sharing my thoughts:
- Regarding "Unpredictable" : I don't think we are like doing very
unpredictable releases. It should be a formal mail, like Release x.y.z and
then the RM
Hello HIVE Dev,
I would like to discuss/propose incremental and cadence predictable process for
HIVE releases.
https://hive.apache.org/general/downloads/
Currently, our releases have a very random span in between, and those have
sometimes caused problems like-
1. All downstream and end
