Build Master: Scheduling
Jonathan M Davis
jmdavisProg at gmx.com
Sun Nov 17 15:24:45 PST 2013
On Thursday, November 14, 2013 14:55:44 Dicebot wrote:
> On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> > ...
> >
> > Your thoughts and concerns please.
>
> Key problem here is that you call by beta something that is
> really not a beta. It is short term support release similar to
> ones we currently have with a shorter release schedule. And if it
> is _really_ supposed to be beta (== with some potentially unfixed
> regressions remaining) it is not really usable even in bleeding
> edge code.
>
> I have been proposing for ages to take existing
> http://wiki.dlang.org/Release_Process and define long-term
> support releases on top of it (== "normal" releases in your
> proposal). That way one can do releases once in 2 months to keep
> stuff going and mark ones as LTS once in a 6 months (with
> intention to backport non-breaking fixes into last 2 LTS) for
> users that want more stability.
>
> It fulfills same goals but does not result in broken releases /
> confusing naming.
I think that it makes some sense to continue to do releases more or less as we
have (though hopefully more frequently - monthly or bi-monthly) but to have an
"LTS" release every six months and then update that LTS branch and do patch
releases for it whenever there's a critical bug that needs to be fixed. So, we
have the LTS version which only gets critical patches, and the normal one
which gets everything. But we don't try and treat the normal one as a beta or
anything like that. That's a horrible idea IMHO, and will just lead to
everyone using git head.
However, even with the LTS release, we should be _very_ restrictive on what
bugs get backported, because it's actually the bug fixes which cause the most
bugs and code breakage.
But I think that the idea should be that the LTS release is for those who need
things to change as little as possible but still get fixes for bugs that really
need them, whereas the normal releases should be what most everyone uses and
that we not try and avoid having most folks use the releases which can include
new features or other major changes.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list