[ANNOUNCE] Apache Subversion 1.9.0-rc3 released

[Branko Čibej]

I'm happy to announce the release of Apache Subversion 1.9.0-rc3.
Please choose the mirror closest to you by visiting:

http://subversion.apache.org/download/#pre-releases

The SHA1 checksums are:

26fcfa53e32e3f83724327d3fdb965dc28253260 subversion-1.9.0-rc3.tar.bz2
1c7386c0d32cf9789967d711415ccc28041295a9 subversion-1.9.0-rc3.tar.gz
f50cf8dd14a46c882c05f5436f1dec97169b58c0 subversion-1.9.0-rc3.zip

PGP Signatures are available at:

http://www.apache.org/dist/subversion/subversion-1.9.0-rc3.tar.bz2.asc
http://www.apache.org/dist/subversion/subversion-1.9.0-rc3.tar.gz.asc
http://www.apache.org/dist/subversion/subversion-1.9.0-rc3.zip.asc

For this release, the following people have provided PGP signatures:

   Bert Huijben [4096R/CCC8E1DF] with fingerprint:
3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Branko Čibej [4096R/A347943F] with fingerprint:
BA3C 15B1 337C F0FB 222B  D41A 1BCA 6586 A347 943F
   Johan Corveleyn [4096R/010C8AAD] with fingerprint:
8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
   Julian Foad [4096R/4EECC493] with fingerprint:
6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493
   Philip Martin [2048R/ED1A599C] with fingerprint:
A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Stefan Fuhrmann [4096R/57921ACC] with fingerprint:
056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC

This is a pre-release for what will eventually become Apache Subversion
1.9.0.  It may contain known issues, a complete list of
1.9.0-blocking issues can be found here:


http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_milestone=1.9.0

A pre-release means the Subversion developers feel that this release
is ready for widespread testing by the community.  There are known issues
(and unknown ones!), so please use it at your own risk, though we do
encourage people to test this release thoroughly.  Of particular note, please
remember than persistent data, such as the working copy or repository
formats may change before the final release, and there may not be an
upgrade path from the pre-releases to the final.

As a note to operating system distro packagers: while we wish to have this
release candidate widely tested, we do not feel that it is ready for packaging
and providing to end-users through a distro package system.  Packaging a
release candidate poses many problems, the biggest being that our policy lets
us break compatibility between the release candidate and the final release, if
we find something serious enough.  Having many users depending on a release
candidate through their distro would cause no end of pain and frustration that
we do not want to have to deal with.  However, if your distro has a branch that
is clearly labeled as containing experimental and often broken software, and
explicitly destined to consenting developers and integrators only, then we're
okay with packaging the release candidate there.  Just don't let it near the
end users please.


Release notes for the 1.9.x release series may be found at:

http://subversion.apache.org/docs/release-notes/1.9.html

You can find the list of changes between 1.9.0-rc3 and earlier versions at:

http://svn.apache.org/repos/asf/subversion/tags/1.9.0-rc3/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team




signature.asc
Description: OpenPGP digital signature

Re: subversion-1.9.0-rc2 autogen.sh script breaks "/usr/share/aclocal" discovery on Fedora 21 and otherws

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, Jul 13, 2015 at 23:12:16 +:
> Nico Kadel-Garcia wrote on Sun, Jul 12, 2015 at 14:08:25 -0400:
> > On Sun, Jul 12, 2015 at 3:09 AM, Daniel Shahaf  
> > wrote:
> > > Nico Kadel-Garcia wrote on Sun, Jul 12, 2015 at 01:24:56 -0400:
> > >> +if [ -L "$ltpath" -a "$ltpath" = "/bin" ]; then
> > >> +# Avoid "/bin" symlink to "/usr/bin" confusion
> > >> +ltpath=/usr/bin
> > >> +fi
> > >
> > > We can't presume that /usr/bin is the target of /bin when the latter is
> > > a symlink.  That's not necessarily true everywhere.
> > 
> > Can you think of a specific instance where "libtool" is in
> > "/bin/libtool" where this would not apply? In all circumstance I know
> > of where "/bin" is a symlink with "libtoolize" in it, it's the case,
> > 
> 
> Actually I can, but that's besides the point.  We need autogen.sh to
> work no matter what the /bin symlink points to.

In more words: it's entirely possible that there is a system where /bin
is a symlink that points to some location other than /usr/bin, and we
need to work on that system too — even if we don't know about it.

(Of course this whole sub-discussion becomes moot if we use
--print-ac-dir, as discussed elsethread.)

Cheers,

Daniel