ILTS just doesn't make sense with a release cycle that's already set to be
one of the slowest in the Linux world. Debian, and now Devuan releases are
extremely conservative. N+1 cycles are good enough. The manpower that would
be required to maintain 4, 5, or more more supported "released" branches is
manpower that could be better spent elsewhere - improving the release
engineering and working through the backlog of bugs.

<rant>
IMHO the enterprise mindset does more harm than good, because deferring
change creates a vicious cycle, where the accumulated breakage of half a
decade between each release prompts cries for even more time, and more
breakage, meanwhile more dirty hacks and accumulated cruft build up within
that organization's infrastructure, adding to the fragility and
breakage. Meanwhile, developers demand newer libraries, runtimes, and
components for applications - as the "solution" to any problem from
upstream maintainers is ALWAYS to run the latest stable upstream version
come hell or high water, and the first time that developer tries to use a
feature that's the documentation says is there but's not in the decade-old
version that happens to be available, they demand updates - which then get
compiled from source or installed from packages obtained from god knows
where, along with a slew of dependencies.

A reasonable, conservative release cycle, coupled with the 4 branch
(unstable, testing, stable, oldstable) and a FIRM n+1 support policy
minimizes the cost of support, sets firm expectations for EOL, and provides
more than enough time to test, qualify, and migrate, while forcing
organizations to address their infrastructure's growing technical debt
while they still have the institutional memory to understand how. If you
can't do this in the 2 years that typically go between releases, then your
problem is not that the releases are too fast, it's that your organization
is institutionally incompetent.
</rant>
On Fri, Jul 17, 2015 at 12:57 AM James Powell <james4591@???> wrote:

> An LTS branch isn't needed if you do version controlled releases and
> sponsor support for versioned releases for at least 3-4 versions back.
>
> To be fair, I've used Slackware long enough to see how maintaining a
> versioned release can go right, and seen enough of Ubuntu to see how it can
> go horribly wrong.
>
> Devuan should have at least 3 branches.
>
> Versioned releases released on annual cycles as packages mature.
>
> Unstable but tested branch similar to Slackware-Current in which Versioned
> releases are established.
>
> Experimental branch for new packages that aren't tested or just slightly
> tested for buildability in a working environment that will determine what
> goes into Unstable. This branch should also NOT be part of the mainline
> availability but accessible through a git/svn/cvs client only for safety
> reasons, namely preventing someone from blowing their system to Hell.
>
> As releases mature, 1.0 would be maintained until the fourth or fifth
> release year following, then pastured, regardless of version number. The
> only time the main number should be changed is IF and ONLY IF glibc is
> updated, otherwise 1.0 would transmigrate to 1.1.
>
> How does that sound?
>
> Sent from my Windows Phone
> ------------------------------
> From: Adam Borowski <kilobyte@???>
> Sent: ‎7/‎16/‎2015 9:44 PM
> To: dng@???
> Subject: Re: [DNG] devuan LTS
>
> On Thu, Jul 16, 2015 at 09:39:41PM -0700, Gregory Nowak wrote:
> > the recent discussions here have made me think about what features I
> > would like devuan to have which debian doesn't currently have. One
> > feature that comes to mind is a long term support branch like what
> > ubuntu has.
>
> Since squeeze, every release has amd64+i386-only long term support.
>
> --
> ⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
> ⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠀⠀⠀⠀⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠀⠀⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
> (https://github.com/kilobyte/braillefont for this hack)
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>