On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote:
> 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.
So it sounds like we can stick to the current release model after all?
Short of fixing JavaHL API issues somehow (with class loaders or whatever),
Subclipse could choose to be compatible with LTS releases only, could it not?
This seems to be what some Linux distributions are doing now. I don't recall
any other downstream projects raising concerns over our new release model.
I would not want to change the release model again after such a short time
frame. As long as we can manage to stick to the new schedule I think we
should stick to it. Should we find that there is nothing to release after
6 months we can just skip or postpone a release. Should the schedule turn out
to be unworkable in the long term we will have to change it again in any case.
Received on 2019-08-21 12:48:06 CEST