On Tue, Aug 20, 2019 at 11:46 AM Julian Foad <julianfoad_at_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.
Received on 2019-08-20 19:14:24 CEST