On Thu, Oct 24, 2019 at 02:46:39AM +0000, Daniel Shahaf wrote:
> Nathan Hartman wrote on Wed, Oct 23, 2019 at 01:11:19 -0400:
> > James McCoy wrote:
> > > FWIW, since we switched to the new release model, I (in my capacity as
> > > packager for Debian) basically ignore non-LTS releases. It's easier to
> > > ignore them, since I know I only want an LTS release in Debian's
> > > release, and would rather not risk getting "stuck" with a non-LTS
> > > release when Debian freezes.
> >
> > And this is completely okay!
> >
> > I use Debian myself. Most Debian packages "lag" behind the latest and
> > greatest. The same is true of other stability-oriented OSes. When you
> > have 50,000 packages in your repositories and a whole dependency hell
> > between them (circular / diamond dependencies, anyone?), you have to
> > move forward cautiously. This is where users must decide if they favor
> > stability or new features and choose their distro accordingly. It's a
> > trade-off.
> >
> > Thank you for maintaining the Debian package. It works great!
>
> Nathan, if I understood James correctly, he's saying that he doesn't package
> non-LTS releases even for Debian unstable and Debian testing, so users of those
> flavours of Debian will only be served LTS versions of Subversion by Debian.
> That _is_ noteworthy: those two flavours of Debian normally have little lag behind
> upstream. It's only the "stable" flavour that typically (by design) has lag.
>
> The upshot of this is that users of Debian testing/unstable, which are by and
> large "low lag" distros, don't get STS releases of Subversion.
>
> James, please correct me if I'm wrong.
I do not think that this is a problem. LTS releases are the equivalent
of releases we used to publish before the release schedule was changed.
Non-LTS releases are just additional releases which give us a chance to
get more feedback and give users regular access to new features and fixes.
What matters is that some of the systems out there run our regular releases.
And indeed, it is not as if everyone was using our LTS releases only.
OpenBSD releases usually ship a very recent release of SVN, which works
well because their release cycle is also 6 months long.
FreeBSD ships 1.10 as part of their base system (it would make sense for
them to stick to LTS).
NetBSD pkgsrc ships 1.12.
Fedora seems to ship 1.10 and 1.12.
ArchLinux ships 1.12.
OpenSUSE has 1.12, 1.9, and 1.8 available via their build service (I am not
sure what shipped in their latest release).
Slackware ships 1.9 in their release and carries 1.12 in -current.
I am not going to go on with this list. I think it already shows that there
is sufficient interest in our non-LTS releases, and that downstream consumers
are making choices for their users about LTS/non-LTS SVN releases, such that
the version of SVN shipped aligns with their respective project release cycles
and stability goals. This is good.
Received on 2019-10-24 11:39:05 CEST