svn binary packages for macOS

[Sean McBride]

Hi all,

Not sure who maintains the list of binary packages here:

<https://subversion.apache.org/packages.html>

But you should probably remove WANdisco from the list. They haven't published one since version 1.11.1 in 2019 (for any OS):

<https://www.wandisco.com/source-code-management/subversion>

That version of course has unfixed security issues, so should not be encouraged.

Alas, that seems to mean there are no other binary distributions for macOS, unless anyone knows of any?

If being open source is not required, you could list these two:

<https://www.versionsapp.com/>
<https://cornerstone.assembla.com/>

Cheers,

Sean

[Mark Phippard]

On Sun, Oct 3, 2021 at 8:54 AM Sean McBride <se...@rogue-research.com> wrote:

> Alas, that seems to mean there are no other binary distributions for macOS, unless anyone knows of any?

Homebrew and MacPorts are both listed. Honestly once those projects
supported SVN it kind of removed all of the incentive to publish a
package. That is why we stopped providing one from CollabNet and
removed our listing from that page. I would guess it had to do with
why WanDisco stopped too. If you are doing software development on OSX
it is pretty rare to not eventually need to use Homebrew or MacPorts.
Once you do, then installing SVN is trivial.

I personally use Homebrew. The SVN package is all precompiled so it is
easy to install. Myself and other SVN devs have even improved the
formula over the years. For example, I have provided improvements over
the years so that the JavaHL library is included by default and I
helped to get the package fully working on the new Apple Silicon.

Mark

[Sean McBride]

On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said:

>Homebrew and MacPorts are both listed.

I saw that, but I thought they required Xcode...

>Honestly once those projects
>supported SVN it kind of removed all of the incentive to publish a
>package. That is why we stopped providing one from CollabNet and
>removed our listing from that page. I would guess it had to do with
>why WanDisco stopped too.

I see. Do you agree Wandisco's should be removed from the website listing at this point?

>If you are doing software development on OSX
>it is pretty rare to not eventually need to use Homebrew or MacPorts.
>Once you do, then installing SVN is trivial.

Most svn users at my office are not doing software development.

>I personally use Homebrew. The SVN package is all precompiled so it is
>easy to install.

Ah, so I guess Xcode is not required. Will try...

>Myself and other SVN devs have even improved the
>formula over the years. For example, I have provided improvements over
>the years so that the JavaHL library is included by default and I
>helped to get the package fully working on the new Apple Silicon.

Thanks for your work!

Sean

[Mark Phippard]

On Sun, Oct 3, 2021 at 7:17 PM Sean McBride <se...@rogue-research.com> wrote:

> On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said:
>
> >Homebrew and MacPorts are both listed.
>
> I saw that, but I thought they required Xcode...
>
> >Honestly once those projects
> >supported SVN it kind of removed all of the incentive to publish a
> >package. That is why we stopped providing one from CollabNet and
> >removed our listing from that page. I would guess it had to do with
> >why WanDisco stopped too.
>
> I see. Do you agree Wandisco's should be removed from the website listing at this point?

If they no longer intend to provide newer versions then yes I think it
should be removed. I would prefer someone else do it though simply
because I used to work for a competitor of WanDisco and would not want
anyone there to think that was a motive. I tried to remove any
CollabNet package from this page that we were no longer maintaining,
such as when we stopped providing new binaries for OSX and Solaris.

Mark

[Daniel Sahlberg]

I don't pretend to know anything about Macos, but WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version of Mac OS supported by Fink/Homebrew/MacPorts? If not, then I think it is reasonable to keep the link - at least until 1.10 is EOL (or we find a client side security issue in 1.10, there was a CVE fix in 1.10.7 but only server side). By the way, the situation for Linux and Windows is just the same so we should make the same decision for all platforms.

Checking further, CollabNet is providing packages for 1.12.2. That one is for sure EOL. I downloaded and installed Subversion Edge 5.2.4, which seems to contain Apache HTTP Server 2.4.39 and Subversion 1.8.19. It is not evident to me if CollabNet is providing any Subversion services in any other product.

Cornerstone was last updated 2019-12-31 so it is based on either 1.13.0 or 1.10.6 if they used the lastest version on the time of release.

As for VersionsApp it seems current and active and I can't see any reason not including it.

If "only providing outdated versions" is a reason for de-listing then sadly both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can edit the website but I'd appreciate if anyone else in PMC would give their opinion on policy.

Kind regards

Daniel Sahlberg

[Sean McBride]

On Mon, 4 Oct 2021 17:23:56 +0200, Daniel Sahlberg said:

>I don't pretend to know anything about Macos, but WANdisco is providing
>Subversion 1.10.6 for Mac OS 10.9. Is that version of Mac OS supported by
>Fink/Homebrew/MacPorts? If not, then I think it is reasonable to keep the
>link - at least until 1.10 is EOL (or we find a client side security issue
>in 1.10, there was a CVE fix in 1.10.7 but only server side). By the way,
>the situation for Linux and Windows is just the same so we should make the
>same decision for all platforms.

That's a good point. The WANDisco builds are still useful for old macOS. I retract my suggestion to remove it. Perhaps just put a note that they are not current?

>Cornerstone was last updated 2019-12-31 so it is based on either 1.13.0 or
>1.10.6 if they used the lastest version on the time of release.

I would still include it, unlike Versions.app it supports things like shelving.

Sean

[Mark Phippard]

On Mon, Oct 4, 2021 at 11:24 AM Daniel Sahlberg
<daniel.l...@gmail.com> wrote:

> If "only providing outdated versions" is a reason for de-listing then sadly both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can edit the website but I'd appreciate if anyone else in PMC would give their opinion on policy.

My recommendation is we discuss and create a policy, add it to the
page and then we can enforce it. I would expect the policy would be
related to providing our LTS version and the only question is whether
we want to require the latest LTS version be made available or just
that one of our still supported LTS versions is available. Perhaps the
latter could be an exception if there is some OS that cannot support a
newer LTS for some reason.

Historically, we only allowed distributions of our command line
binaries to be listed. TortoiseSVN was the first exception we made and
that was after they added the command line binaries as part of their
installer. But AFAIK, clients like Cornerstone and Versions are GUI
clients. Other clients with a long and close relationship with SVN
such as Subclipse and AnkhSVN have never been listed on this page for
that reason.

Thanks

Mark

[Nathan Hartman]

On Mon, Oct 4, 2021 at 11:44 AM Mark Phippard <mark...@gmail.com> wrote:
>
> On Mon, Oct 4, 2021 at 11:24 AM Daniel Sahlberg
> <daniel.l...@gmail.com> wrote:
>
> > If "only providing outdated versions" is a reason for de-listing then sadly both CollabNet and WANdisco should go (at least when 1.10 is EOL). I can edit the website but I'd appreciate if anyone else in PMC would give their opinion on policy.
>
> My recommendation is we discuss and create a policy, add it to the
> page and then we can enforce it. I would expect the policy would be
> related to providing our LTS version and the only question is whether
> we want to require the latest LTS version be made available or just
> that one of our still supported LTS versions is available. Perhaps the
> latter could be an exception if there is some OS that cannot support a
> newer LTS for some reason.

Some websites have a link to "older releases" which are listed on a
separate page. Instead of removing mention of binaries, we could move
them to a separate page (called "older 3rd party binaries" rather than
"older releases" since they're not our binaries). That page could have
a prominent note about the disadvantages of running older unsupported
releases, but leave the choice in the user's hands. Thoughts?

Cheers,
Nathan

[Mark Phippard]

On Oct 4, 2021, at 12:00 PM, Nathan Hartman <hartman...@gmail.com> wrote:

My suggestion would be that we start simple (for us) and say that we want anyone listed to provide the latest available LTS version in order to be listed.

Then as we get requests to add packages back in we can discuss the exceptions and why we should allow them. One exception I think we should make would be Linux/BSD distros. Where we just are showing the commands to install the package for a distro I do not think we should bother getting involved with what version that distro is providing. That said ... if someone thinks we should just not list them if they only provide an old version then I am OK with that too. I think the policies should mainly apply to when we are linking to some external download page.

Mark

[Sean McBride]

On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said:

>I personally use Homebrew. The SVN package is all precompiled so it is
>easy to install. Myself and other SVN devs have even improved the
>formula over the years.

Mark,

Not sure if this is veering off-topic for this list, but I've tried using brew to install svn and it gives me:

------------------
$ brew install --build-bottle subversion
<snip>
Error: The following formulae cannot be installed from bottles and must be
built from source.
openjdk, gdbm, mpdecimal, ca-certificates, openssl@1.1, readline, sqlite, python@3.9, scons, pcre, auto...@2.69, apr and utf8proc
------------------

if I try just:

$ brew install subversion

it ends with:

------------------
==> Installing subversion dependency: openjdk
==> ./configure --disable-warnings-as-errors --with-boot-jdk-jvmargs=-Duser.home=/Users/builder/Library/Caches/Homebrew/java_cache --with-boot-jdk=/private/tmp/openjdk-20211004-15
==> make images
Last 15 lines from /Users/builder/Library/Logs/Homebrew/openjdk/02.make:
watchos(1.0, API_TO_BE_DEPRECATED),
^
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrust.h:357:47: error: expected a version of the form 'major[.minor[.subminor]]'
tvos(2.0, API_TO_BE_DEPRECATED));
... (rest of output omitted)

* All command lines available in /private/tmp/openjdk-20211004-15582-jeery1/jdk17u-jdk-17-ga/build/macosx-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.

make[1]: *** [main] Error 2
make: *** [images] Error 2

Do not report this issue to Homebrew/brew or Homebrew/core!

These open issues may also help:
openjdk: try to reproduce java.lang.UnsatisfiedLinkError https://github.com/Homebrew/homebrew-core/pull/84886
OpenJDK is somewhat broken on newer MacOS instances, console is flooded with errors when using JMeter, AdoptOpenJDK has no issues https://github.com/Homebrew/homebrew-core/issues/66953
------------------

this is on macOS 10.13.6.

I guess I should add backstory: I'm currently using WANDisco's binaries, but the reason I'm looking to update is because of the Let's Encrypt certificate expiring the other day. I'm not totally sure, but I think the cURL and/or OpenSSL/LibreSSL that that svn is using is not dealing well with the expired cert. So I'm looking to try a newer build.

Sean

[Mark Phippard]

On Mon, Oct 4, 2021 at 1:00 PM Sean McBride <se...@rogue-research.com> wrote:
>
> On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said:
>
> >I personally use Homebrew. The SVN package is all precompiled so it is
> >easy to install. Myself and other SVN devs have even improved the
> >formula over the years.
>
> Mark,
>
> Not sure if this is veering off-topic for this list, but I've tried using brew to install svn and it gives me:
>
> ------------------
> $ brew install --build-bottle subversion
> <snip>
> Error: The following formulae cannot be installed from bottles and must be
> built from source.
> openjdk, gdbm, mpdecimal, ca-certificates, openssl@1.1, readline, sqlite, python@3.9, scons, pcre, auto...@2.69, apr and utf8proc
> ------------------
>
> if I try just:
>
> $ brew install subversion

^ that is the command to use. I am not sure why you are having that
problem installing OpenJDK. Maybe you could try this first?

$ brew install openjdk

I will see if I have a Mac on an older version where I can try this. I
am on Apple Silicon now so I am on version 11.6.

One thing that is weird is that openjdk is a build dependency. It
should not be required for installing the bottle. So it is like it is
trying to build from source or something. When I examine the formula I
see:

==> Dependencies
Build: openjdk ✔, pkg-config ✔, python@3.9 ✔, scons ✔, swig ✔
Required: apr ✔, apr-util ✔, gettext ✔, lz4 ✔, openssl@1.1 ✔, utf8proc ✔

So if it is installing the bottle it should not even be trying to
install openjdk.

Mark

[Ryan Schmidt]

On Oct 4, 2021, at 10:23, Daniel Sahlberg wrote:

> WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version of Mac OS supported by Fink/Homebrew/MacPorts?

I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and provides binaries for Mac OS X 10.6 and later. See:

https://ports.macports.org/port/subversion

(The link at https://subversion.apache.org/packages.html#osx should be updated to this.)

My understanding is that Homebrew requires OS X 10.9 or later and recommends macOS 10.14 or later.

On Oct 3, 2021, at 18:17, Sean McBride wrote:

> On Sun, 3 Oct 2021 09:07:04 -0400, Mark Phippard said:
>
>> Homebrew and MacPorts are both listed.
>
> I saw that, but I thought they required Xcode...

MacPorts installation instructions say to install Xcode and the command line tools in order to avoid the circumstance that you might encounter an error message when something has to be compiled that requires those.

If what you are compiling does not require Xcode but can make do with the command line tools (as most things can), then you only need to install the command line tools, not Xcode.

And in the most common case that what you want to install has already been compiled by our build servers and is available as a binary download, then you need neither Xcode nor the command line tools.

You're welcome to install MacPorts without installing Xcode or the command line tools and try to install a port. If it works, great, if not, the error message should indicate if Xcode is required. If it indicates that, install Xcode; if not, install the command line tools.

[Sean McBride]

On Tue, 5 Oct 2021 17:45:39 -0500, Ryan Schmidt said:

>I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later
>and provides binaries for Mac OS X 10.6 and later. See:
>
>https://ports.macports.org/port/subversion

Ryan,

Thanks! That worked for me. It was able to install svn 1.14.1 on macOS 10.13.6.

Even better, it fixed my root issue, which is that since the Sept 30 Let's Encrypt certificate expiration, the WANDisco 1.11.1 binaries (for whatever reason) fail to `svn up` but it now works with the MacPorts 1.14.1 installation.

Cheers,

Sean

[Daniel Sahlberg]

Den ons 6 okt. 2021 kl 00:46 skrev Ryan Schmidt <subvers...@ryandesign.com>:

On Oct 4, 2021, at 10:23, Daniel Sahlberg wrote:

> WANdisco is providing Subversion 1.10.6 for Mac OS 10.9. Is that version of Mac OS supported by Fink/Homebrew/MacPorts?

I am a manager of MacPorts. MacPorts supports Mac OS X 10.4 and later and provides binaries for Mac OS X 10.6 and later. See:

https://ports.macports.org/port/subversion

(The link at https://subversion.apache.org/packages.html#osx should be updated to this.)

My understanding is that Homebrew requires OS X 10.9 or later and recommends macOS 10.14 or later.

Thank you Ryan for your effort in providing Subversion on OS X as far back as 10.6 (and 10.4)!

Since we don't explicitly list the supported versions on other OSes, I hesitate to add it to MacPorts. That kind of information will grow stale in time and I don't think we will be able to maintain it as projects move on in what versions they support. (I'm open to other opinions though!)

Kind regards,

Daniel

[Daniel Sahlberg]

Den mån 4 okt. 2021 kl 17:44 skrev Mark Phippard <mark...@gmail.com>:

Historically, we only allowed distributions of our command line
binaries to be listed. TortoiseSVN was the first exception we made and
that was after they added the command line binaries as part of their
installer. But AFAIK, clients like Cornerstone and Versions are GUI
clients. Other clients with a long and close relationship with SVN
such as Subclipse and AnkhSVN have never been listed on this page for
that reason.

Thank you for pointing this out. Reading the website carefully it actually says "Note also that this list does not include distributions of larger collections of software of which Subversion is but one piece.".

Until we change this policy, I believe Cornerstone and Versions should not be listed.

On the other hand, I think we could change the policy. I think that the more help we can give to our users (both in the sense of "end users" and "consumers of our API") the better for everyone. Of course, we should then list Subclipse and AnkhSVN as well.

I'll come back with another suggestion of change in policy as a reply to a separate e-mail.

Kind regards,

Daniel Sahlberg

[Daniel Sahlberg]

Thanks Mark for your excellent background information.

I second Mark's suggestion that we should only list those providing recent versions. Would this be a reasonable definition: "Any software listed should provide the latest bugfix of any supported version", where "version" is 1.10, 1.14 etc.

I realise this would rule out both WANdisco and CollabNet immediately since they don't provide the latest bugfix release. We could delay implementing the policy until april next year (when 1.10 is out of support).

Kind regards,

Daniel Sahlberg

[Mark Phippard]

On Sat, Oct 16, 2021 at 8:57 AM Daniel Sahlberg
<daniel.l...@gmail.com> wrote:

> I second Mark's suggestion that we should only list those providing recent versions. Would this be a reasonable definition: "Any software listed should provide the latest bugfix of any supported version", where "version" is 1.10, 1.14 etc.
>
> I realise this would rule out both WANdisco and CollabNet immediately since they don't provide the latest bugfix release. We could delay implementing the policy until april next year (when 1.10 is out of support).
>

As long as we are in agreement about what we think the policy ought to
be we should just go ahead and do it. I feel like it leads to 3
possibilities for any packagers that we remove from our page:

1. This motivates them to update their packages and get listed again.

2. This reveals that they are no longer going to provide new packages

3. They come back to us with some kind of valid reasons that we were
not aware of and we adjust the policy

I personally feel like all 3 of these outcomes are better for the
Subversion project than the current status quo.

In terms of the policy, I think it should be that our latest LTS
release must be available. If they have other packages available that
is fine but the latest LTS must be one of them. In terms of the types
of exceptions I could envision, perhaps we will discover it is really
difficult to package the latest LTS for certain older distros and so
they need to provide an older version. I would be OK with an exception
like this but I would prefer to have the packagers raise it to us.

Mark

[Nathan Hartman]

On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard <mark...@gmail.com> wrote:
>
> In terms of the policy, I think it should be that our latest LTS
> release must be available. If they have other packages available that
> is fine but the latest LTS must be one of them. In terms of the types
> of exceptions I could envision, perhaps we will discover it is really
> difficult to package the latest LTS for certain older distros and so
> they need to provide an older version. I would be OK with an exception
> like this but I would prefer to have the packagers raise it to us.
>
> Mark

I'm not opposed to this, but it might be a little tricky for OS
distros that freeze package versions. Debian for example. I haven't
checked what the current stable (bullseye) has, but I'm still on the
oldstable (buster) which supplies 1.10.x. I'm running a recent trunk
build though, heh heh :-)

I'm not proposing an exception (and I'm not a packager); rather I'm
suggesting to consider a package compliant as long as it was a
supported LTS release at the time of the packager's version freeze
and security issues continue to be patched.

Thoughts?

Nathan

[Nico Kadel-Garcia]

On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman
<hartman...@gmail.com> wrote:
>
> On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard <mark...@gmail.com> wrote:
> >
> > In terms of the policy, I think it should be that our latest LTS
> > release must be available. If they have other packages available that
> > is fine but the latest LTS must be one of them. In terms of the types
> > of exceptions I could envision, perhaps we will discover it is really
> > difficult to package the latest LTS for certain older distros and so
> > they need to provide an older version. I would be OK with an exception
> > like this but I would prefer to have the packagers raise it to us.
> >
> > Mark
>
>
> I'm not opposed to this, but it might be a little tricky for OS
> distros that freeze package versions. Debian for example. I haven't
> checked what the current stable (bullseye) has, but I'm still on the
> oldstable (buster) which supplies 1.10.x. I'm running a recent trunk
> build though, heh heh :-)

I can vouch for this in the Red Hat world. I used to publish ports of
Subversion over at repoforge, but the various dependency updates got a
bit out of hand for me to continue after Repoforge ended. And EPEL
refuses to replace any RHEL published tools. Red Hat sometimes
publishes updates as part of their "SCL" or software collections
library, but those can be really finicky to work with.

[Mark Phippard]

On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman
<hartman...@gmail.com> wrote:
>

My feeling is that our policy should focus on the situation where we
are linking to an external website where the user downloads some
package from them. For the Linux/BSD distros, and even Homebrew and
MacPorts on MacOS, we are just telling the user that these package
managers offer Subversion and maybe we list the commands to run in
order to install the package. I do not think we need to police the
version as heavily in this case. Especially with the Linux distros
since they selectively backport patches so their version never
perfectly matches ours and the distro provides support for their
packages.

That said, the only problematic links on our current page are the ones
from CollabNet and WanDisco. I have not verified WanDisco I am just
taking the word of the people in this thread. Given that both of these
were vendors trying to sell support and requiring registration to even
get the download, I think we should just remove all of those links. If
either of them ask to be put back we can tell them the requirement is
that they offer the latest LTS version.

The other links on the page all generally look good already.

Mark

[Nathan Hartman]

+1

That said, the only problematic links on our current page are the ones
from CollabNet and WanDisco. I have not verified WanDisco I am just
taking the word of the people in this thread. Given that both of these
were vendors trying to sell support and requiring registration to even
get the download, I think we should just remove all of those links. If
either of them ask to be put back we can tell them the requirement is
that they offer the latest LTS version.

Would it make sense to give them a heads up before removing the links in case they would like to release newer packages and remain on the list?

Cheers,

Nathan 

[Daniel Sahlberg]

Yes, if we have any contact channels (I'm not sure about sending to an anonymous info address) and as long as it doesn't violate ASF vendor neutrality. It is about caring for the ecosystem. Nathan, can you do this with the PMC chair hat?

Kind regards,

Daniel

[Nathan Hartman]

On Mon, Oct 18, 2021 at 2:55 AM Daniel Sahlberg
<daniel.l...@gmail.com> wrote:
>> Would it make sense to give them a heads up before removing the links in case they would like to release newer packages and remain on the list?
>
>
> Yes, if we have any contact channels (I'm not sure about sending to an anonymous info address) and as long as it doesn't violate ASF vendor neutrality. It is about caring for the ecosystem. Nathan, can you do this with the PMC chair hat?

Apologies for the delayed reply...

I'm also not too sure about sending to an anonymous info address. If
someone knows who is the proper contact, I'll be happy to send a
message.

Cheers,
Nathan

[Ryan Schmidt]

On Oct 16, 2021, at 07:18, Daniel Sahlberg wrote:

I didn't mean to suggest that you should add version information to the MacPorts listing. I meant to request that someone please change the URL that is hyperlinked to the word "MacPorts" on that page from the one that's currently there, which is outdated, to the new one which I provided above.

[Daniel Sahlberg]

Den mån 8 nov. 2021 kl 16:57 skrev Ryan Schmidt
<subvers...@ryandesign.com>:

My bad, sorry about the misunderstanding. I've committed the change as
r1894844. Is it better now?

Kind regards
Daniel

[Daniel Sahlberg]

There has been some discussion but I don't think there was an actual
decision taken. So I'm throwing in a suggestion to add the following
text to packages.html (just below the regarding "larger collections of
software", and before the Centos Linux header):

<p>A condition to be listed is to provide "reasonably new" versions.
This should be interpreted as the latest patch release of any of the
supported versions (at the time of writing: either of 1.10.6 or 1.14.1).
The rule will be implemented with a fair amount of flexibility to
allow time to release new packages, as well as any considerations
regarding the release process. Please discuss at the <a
href="mailto:us...@subversion.apache.org">Subversion users mailing
list</a>.</p>

I believe it is reasonable to accept someone distributing only 1.10.6
since there may be acceptable reasons not to distribute 1.14.1 (for
example dependencies that are not possible to build on a certain
platform).

I added the "considerations regarding the release process" as a way to
ignore Linux distributions since they might ship what was current at
the time of their release and backport any important security fixes.

If it is ok to make the change, I suggest that we let it soak for a
while before reviewing and reviewing and removing those not
conformant.

Kind regards,
Daniel

[Ryan Schmidt]

On Nov 8, 2021, at 12:21, Daniel Sahlberg wrote:

Yes! Thanks.

[Nathan Hartman]

On Mon, Nov 8, 2021 at 1:42 PM Daniel Sahlberg
<daniel.l...@gmail.com> wrote:
> There has been some discussion but I don't think there was an actual
> decision taken. So I'm throwing in a suggestion to add the following
> text to packages.html (just below the regarding "larger collections of
> software", and before the Centos Linux header):
>
> <p>A condition to be listed is to provide "reasonably new" versions.
> This should be interpreted as the latest patch release of any of the
> supported versions (at the time of writing: either of 1.10.6 or 1.14.1).
> The rule will be implemented with a fair amount of flexibility to
> allow time to release new packages, as well as any considerations
> regarding the release process. Please discuss at the <a
> href="mailto:us...@subversion.apache.org">Subversion users mailing
> list</a>.</p>
>
> I believe it is reasonable to accept someone distributing only 1.10.6
> since there may be acceptable reasons not to distribute 1.14.1 (for
> example dependencies that are not possible to build on a certain
> platform).
>
> I added the "considerations regarding the release process" as a way to
> ignore Linux distributions since they might ship what was current at
> the time of their release and backport any important security fixes.

It could be included directly in the text itself. For example:

<p>A condition to be listed is to keep current with security fixes by
offering the latest supported patch release or by backporting
security patches. The rule will be implemented with a fair amount
of flexibility...

Cheers,
Nathan

[Daniel Sahlberg]

Thanks for the feedback. I copied verbatim and committed as r1894956

Kind regards,
Daniel