On Tue, Aug 20, 2019 at 11:46 AM Julian Foad <julianf...@apache.org> wrote:
> Julian Foad wrote: > > [...] OR > > > > * Each version can add APIs but cannot remove or break existing APIs? > > (Like our current rules for minor releases.) > > Reading back what I've just written, it seems I'm completely missing > something. If we take that approach (API changes allowed), then > everything I wrote doesn't seem to amount to anything that would make a > real difference to you. > > Can you clarify the source of the difficulties you experience, and what > we could change that would help? > I do not have any specific recommendations. I would say first and foremost do what we think is best for this project and might help attract more contributions. Probably the thing that would help me the most would be if the releases slowed down. If we want them on a schedule then do it every 12 months instead of 6. Maybe do more patch releases in between if we want to get non API changes delivered sooner. As I said before, I understand the idea behind frequent releases. That said, with so little activity happening I am not in favor of us doing releases because the calendar says we have to. If there is nothing worthy of a release why are we pushing them so hard when it creates all of this work for our community. In my specific scenario with Subclipse things are just hard and I do not think anything can be done to help. Since the native libraries for the API we need lives outside of our control we always have a problem of the version to support. I cannot just live on the latest version when the major Unix distros are on older versions etc. Any solution is complicated. I do not think TortoiseSVN, as a counter example, has these problems at all. And the frequent releases I believe have historically been good for that client to have. Sorry not much help. -- Thanks Mark Phippard http://markphip.blogspot.com/
