Re: What comes after 1.12?

[Mark Phippard]

On Wed, Aug 21, 2019 at 6:47 AM Stefan Sperling  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/

Re: What comes after 1.12?

[Mark Phippard]

On Tue, Aug 20, 2019 at 7:04 PM Branko Čibej  wrote:

> On 20.08.2019 17:46, Julian Foad 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.
>
> I suspect that the real issue is that a consumer of JavaHL cannot
> trivially rely on compile-time version checks to decide which version of
> the API to use (and, as a consequence, which features it can expose). In
> Java, you have to do this with class loaders and other unspeakable
> horrors. So relying on the 1.8 *API* makes a kind of sense, since we do
> promise backwards compatibility on that level.
>


At the Java source code level, yes we just write to the 1.8 API and that
works fine.  The problem is delivery.  We have to include that JavaHL "jar"
part of the API with Subclipse and that has to match the native libraries
because of how JNI works.  We cannot use the 1.8 JAR with native libraries
from a newer version.  Consequently, we have to provide Eclipse plugins for
each SVN version that delivers the right java part.  This is not too bad,
the problem is the user experience in Eclipse.  Its UI naturally wants to
encourage the user to install the latest version and so usually the user
runs into problems, hits a forum and maybe figures out how to uninstall the
plugin and install the right version for their native libraries.  The whole
thing sucks.

On Windows, we are able to provide the Java and the native due to some
hacks we are able to exploit in how DLL's are loaded and how JNI works.
There is no equivalent that works for other OS and something about the way
JNI loads libraries makes a static build not an option either. If it were
possible for us to deliver the native libraries then there would be less of
an issue.  Anyway, I am several years past the point where I would have had
enough time and interest to try to make it all work again anyway if an
option were possible.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn commit: r1865522 - /subversion/trunk/subversion/libsvn_subr/sqlite3wrapper.c

[Evgeny Kotkov]

Daniel Shahaf  writes:

> Would it break anything if some application that uses libsvn had
> its own copy of SQLite that was compiled with another
> SQLITE_DEFAULT_MEMSTATUS value?  I don't see anything about that
> in the linked page.

I don't think so, because our amalgamated SQLite has all its symbols marked
as static and is not exposed to anyone else.

Also, this compile option only changes the default value of the corresponding
runtime option (SQLITE_CONFIG_MEMSTATUS), meaning that it can still be
changed later with sqlite3_config().


Thanks,
Evgeny Kotkov

Re: svn commit: r1865523 - /subversion/trunk/subversion/libsvn_subr/sqlite3wrapper.c

[Evgeny Kotkov]

Daniel Shahaf  writes:

> Quoting https://sqlite.org/compile.html#_options_to_omit_features:
>
>  Important Note: The SQLITE_OMIT_* options may not work with
>  the amalgamation. SQLITE_OMIT_* compile-time options usually
>  work correctly only when SQLite is built from canonical
>  source files.
>
> and a bit later:
>
>  Also, not all SQLITE_OMIT_* options are tested. Some
>  SQLITE_OMIT_* options might cause SQLite to malfunction and/or
>  provide incorrect answers.
>
> I think we should:
>
> - Revert r1865523

I see that this option has been supported from its introduction in 2010, and
that it appears to be covered in tests.  Also, since it only affects the
journaling mode, apparently it does not participate in the parser/keyword
generation, which is listed as the reason of not using it with amalgamation:

  https://github.com/sqlite/sqlite/blob/cc3f3d1f055/src/parse.y
  https://github.com/sqlite/sqlite/blob/cc3f3d1f055/tool/mkkeywordhash.c
  https://github.com/sqlite/sqlite/blob/cc3f3d1f055/test/attach4.test#L82
  
https://github.com/sqlite/sqlite/commit/bc6b8d73592ad72e674b10152012170a01c31c62


Thanks,
Evgeny Kotkov

Re: What comes after 1.12?

[Stefan Sperling]

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.

Re: What comes after 1.12?

[Julian Foad]

Julian Foad wrote:
It looks like we need to make this clearer. Thank you for those 
suggestions. I will make some changes.


Changed:
http://subversion.apache.org/download
http://svn.apache.org/r1865613
* download.html
  Add a notice of latest LTS release after notice of latest regular 
release.

  (#recommended-release): Change the title to "Latest regular release".
State the support period.
  (#supported-releases): Change the title to "LTS releases".
State the support period.
  Say "1.10 LTS" instead of just "1.10", and for 1.9, everywhere.

Please do let me know any other improvements you can think of!

- Julian

Re: What comes after 1.12?

[Julian Foad]

Thomas Singer wrote:

What are the LTS releases?


See https://subversion.apache.org/roadmap.html#release-planning

Is this somehow detectable by a user from the 
name? Ubuntu, for example, adds "LTS" to the name of their releases, 
e.g. "18.04 LTS". Maybe at




the title "Other Supported Release(s)" should rather be "LTS-Releases" 
with obvious indication how long they will receive support. And, of 
course, 1.10 should be named 1.10 LTS.


It looks like we need to make this clearer. Thank you for those 
suggestions. I will make some changes.


- Julian

Re: What comes after 1.12?

[Thomas Singer]

What are the LTS releases? Is this somehow detectable by a user from the 
name? Ubuntu, for example, adds "LTS" to the name of their releases, 
e.g. "18.04 LTS". Maybe at




the title "Other Supported Release(s)" should rather be "LTS-Releases" 
with obvious indication how long they will receive support. And, of 
course, 1.10 should be named 1.10 LTS.


Tom


On 21/08/2019 09:07, Julian Foad wrote:

Thomas Singer wrote:

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.


+1


But... we are doing releases on a 24-month schedule. We are calling those "LTS" 
releases. They correspond in purpose and stability and frequency to the old minor 
releases.

What is compelling you to do anything with the new "regular" 6-month releases 
in between LTS releases?

Or did we not communicate sufficiently about the new release schedule?
- Julian

Re: What comes after 1.12?

[Julian Foad]

Thomas Singer wrote:
>> 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.
>
>+1

But... we are doing releases on a 24-month schedule. We are calling those "LTS" 
releases. They correspond in purpose and stability and frequency to the old 
minor releases.

What is compelling you to do anything with the new "regular" 6-month releases 
in between LTS releases?

Or did we not communicate sufficiently about the new release schedule?
- Julian