neilconway commented on issue #16622:
URL: https://github.com/apache/datafusion/issues/16622#issuecomment-5646215967

   @alamb High-level, an LTS in some form could definitely make sense. Coming 
from the more traditional database world, the fact that we have thus far gotten 
away with shipping API-breaking releases every 6-8 weeks is a little surprising 
😅
   
   A few questions that occur to me:
   
   1. Six months is a pretty short support duration for an LTS release. Is that 
long enough that it will sufficiently ease downstream pain?
   2. What should the criteria be for backporting changes to the LTS branch? 
Different projects use different standards here, but the more backports we do, 
the more reviewer time is spent checking them, and the more risk there is of 
regressions and disruptive behavioral changes (breaking API changes are 
presumably easier to avoid via tooling). Postgres has traditionally had a very 
conservative backport policy, for example (but they also support stable 
releases for ~5 years). But maybe coding agents make it more feasible to do 
aggressive backporting?
   3. Should we consider shipping DataFusion releases less often? For example, 
if we shipped a new release every 3-4 months, that would reduce the frequency 
of breaking API changes. It might also make it easier to do press/PR about the 
release (more major improvements to talk about). As an example, we could do DF 
releases every 3-4 months and declare 1 release in 4 to be an LTS.
   
   Ultimately it would be good to understand the perspective better of what our 
downstream users would prefer.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to