Odd-even cycle for daffodil bug-fix and functional releases

[Mike Beckerle <mb...@apache.org>]

It has been suggested that due to the large JIRA issue count (380+) on
Daffodil, that we start a regular odd-even release convention where even
point releases such as 3.2.0 are focused on new major features/function,
and odd point releases like the next one, 3.3.0, are focused on bug fixes,
performance improvements, and other non-functional changes (e.g.,
refactoring and clean-ups).

These are only guidelines/themes. Obviously a given release can contain a
new feature if it becomes a high-priority during the cycle, but the point
would be to give organizations that are embedding Daffodil into their
systems a bit more information for planning.

One thought I had is that this kind of cadence makes sense only for
Daffodil and it's Scala runtime1 back-end.

The C-generating runtime2 backend is still in a cycle of major feature
development, so I wouldn't want to hinder feature development there based
on a bug-fix cadence associated with other parts of Daffodil.

Also this obviously doesn't apply to the new vscode debugger.

Thoughts?

RE: Odd-even cycle for daffodil bug-fix and functional releases

["Interrante, John A (GE Research, US)" <Jo...@ge.com>]

I'm fine with staggering new features and bug fixes in even and odd point releases if that helps reduce the large JIRA issue count.  We can plan to get the bug fix releases out more quickly (give them a deadline of, say, two months and then it's time for new features).

-----Original Message-----
From: Mike Beckerle <mb...@apache.org> 
Sent: Monday, October 18, 2021 1:45 PM
To: dev@daffodil.apache.org
Subject: EXT: Odd-even cycle for daffodil bug-fix and functional releases

It has been suggested that due to the large JIRA issue count (380+) on Daffodil, that we start a regular odd-even release convention where even point releases such as 3.2.0 are focused on new major features/function, and odd point releases like the next one, 3.3.0, are focused on bug fixes, performance improvements, and other non-functional changes (e.g., refactoring and clean-ups).

These are only guidelines/themes. Obviously a given release can contain a new feature if it becomes a high-priority during the cycle, but the point would be to give organizations that are embedding Daffodil into their systems a bit more information for planning.

One thought I had is that this kind of cadence makes sense only for Daffodil and it's Scala runtime1 back-end.

The C-generating runtime2 backend is still in a cycle of major feature development, so I wouldn't want to hinder feature development there based on a bug-fix cadence associated with other parts of Daffodil.

Also this obviously doesn't apply to the new vscode debugger.

Thoughts?