On 20. Nov 2019, at 16:01, Marshall Schor <[email protected]> wrote: > > b) users don't like to upgrade - it's potentially destabilizing, and "busy > work" > usually. So "bothering" our users with excessive upgrades isn't so good. > Example: the new Java release system, where there's 1 long-term-stable release > followed by 2 short releases; I think most people don't bother with the short > term releases...
It is true that users usually do not like to upgrade, but that doesn't mean not to make release, does it? After all, they can decide if they want to upgrade or not. And I think it is good to make releases rather often for various reasons: - the more often you make a release, the more you care to make it a convenient process (i.e. automatize as much as possible); the less mistakes you make during a release; the less you have to review, etc. - those users who are waiting for a particular fix can get it quickly without having to work with SNAPSHOT builds - contributions can make it to a release more quickly which makes it more attractive for people to contribute - it underlines the activity of the project - actually the "upgrade risk" gets smaller because there are less potentially problematic changes between each release - and because of early adopters' feedback, you might be able to fix many of these problems before they even impact on the bulk of the users, simply by putting out another release which circumvents the problem So, if somebody would ask me to go for few and big releases vs. small incremental and frequent released, I'd go for the latter. But I also usually work with a development branch (preparing new feature for the next "big" release) and a maintenance branch (bug fixes and small improvements for the last "big" release) I feel which is necessary ask an additional means of balancing upgrade risks vs. development speed vs. bug-fixing speed. In my "fastest moving" project right now, we have bugfix releases every 2-3 weeks and feature releases every 6-8 weeks. Cheers, -- Richard
