On Wed, Aug 21, 2019 at 6:47 AM Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
>
This got sidetracked by me bringing up Subclipse. Yeah I more or less plan
to just declare support for the LTS version. That said, this only really
might work because the WC format has not changed. If it does, then all bets
are off. TortoiseSVN is always going to use the latest version (and
should). On Windows, everyone has that installed which means their WC
format will be upgraded and that would mean all of their SVN clients also
need to be on that version.
As noted in the other thread, other than the work involved (which is an
issue), Subclipse has no technical problem supporting the latest version on
Windows. It just then creates problems for all the other OS where the user
maybe does not have that version and has to jump through hoops to install
the right older version for their OS.
> 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.
>
As I have said, I think the project should do whatever is best for the
project. I get how frequent releases may be the best way to attract new
contributors. That said, so far it has not done that and in my case and
perhaps others, it may be driving me away from the project faster than I
otherwise would. New releases create a lot of downstream activity that I am
not always prepared to do and which forces me to weigh whether to continue
at all. Dealing with a bunch of questions about "where is 1.12" etc. when
I know the release does not offer anything worth installing just makes me
consider walking away. As long as the project thinks it is getting value
from these releases, that is fine though.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2019-08-21 15:23:48 CEST