I just wanted to add that I agree with all of the points in both of your emails :-)
Peter Am 20.11.2019 um 17:03 schrieb Richard Eckart de Castilho: > On 20. Nov 2019, at 16:01, Marshall Schor <m...@schor.com> 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 -- Dr. Peter Klügl R&D Text Mining/Machine Learning Averbis GmbH Salzstr. 15 79098 Freiburg Germany Fon: +49 761 708 394 0 Fax: +49 761 708 394 10 Email: peter.klu...@averbis.com Web: https://averbis.com Headquarters: Freiburg im Breisgau Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080 Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó
