On 2013-11-15 14:06, Martin Nowak wrote:

> The point is, there has never been a really stable dmd release.
> Using it requires to read the mailing list just like with most beta
> software.
> We won't be able to release a stable compiler every month anytime soon.

True, but a beta would be even less stable.

-- 
/Jacob Carlborg

On Friday, 15 November 2013 at 09:23:27 UTC, luka8088 wrote:
> Yes but not having a delay between the time a new feature is implemented
> and the time it is released is very risky in terms of bugs. Because this
> new features has not been tester properly. And that is a fact.

Common misconception. We have relatively few breaking changes and bugs introduced by new features, much more common are regressions introduced by routine bug fixing (because of all hidden relations)

What is bad with calling those fast releases "betas" is that they will be unusable with current approach to betas. Right now beta is just some snapshot from master which can contain any possible amount of regressions. Point of time when beta is released is point of time when people start actively fixing all those issues and that is the key property. If it becomes just another snapshot with no implies efforts to fix all regressions in relatively short term it gains us nothing over nightly master builds. Other than making actual releases delayed even longer.

On Friday, 15 November 2013 at 12:58:47 UTC, Martin Nowak wrote:
> That's the exact problem with most of the release ideas proposed here, they are terribly inefficient.
> The schedule proposed by Andrew only requires one maintenance branch (point releases) besides the regular beta releases from master. Backporting to a single stable branch should be within our budget.

It is no different than supporting one LTS backporting branch and current actual release branch. Only difference from proposed model is that by calling it "release" you are taking certain responsibilities to get in at least a bit usable shape at the point of release.

DMD releases may have never been stable but they are _much_ more stable than usage of git master HEAD.

On Friday, 15 November 2013 at 07:50:28 UTC, Jacob Carlborg wrote:
> The opposite of an LTS release is _not_ a beta release. It's a regular release. It seems it would be better if the beta release were regular releases and the releases were LTS releases.
>
> I'm having a hard time requiring my users to use anything that is not a release (that is, a beta).

On the other hand, supporting build with 2 versions: latest beta and latest LTS is not a big burden imo (unless you expose bleeding edge features in the api).

On Friday, 15 November 2013 at 15:25:29 UTC, QAston wrote:
> On Friday, 15 November 2013 at 07:50:28 UTC, Jacob Carlborg wrote:

> On the other hand, supporting build with 2 versions: latest beta and latest LTS is not a big burden imo (unless you expose bleeding edge features in the api).

I like the Ubuntu release model. Translated into D would be:

- a (regular) release every 2 months
  * supported until the next (regular) release gets out
  * point releases will follow every 2 weeks, with bug fixes only (better a short list of bugs well fixed, that is without regressions, than a longer list with plenty of regressions)

- each 3rd (regular) release, that is every 6 months, will be a LTS release
  * supported until the next LTS release gets out (possibly longer)
  * point releases will follow every 2 weeks, with bug fixes only (unless causing serious code breakage)

The first 2 (regular) releases will introduce bugfixes as well as new features, while the LTS release will (aim to) provide the new features from the above regular releases, plus bug fixes. So, for creating a LTS release, the first for months will be of features and bug fixes, while the latter 2 months will be just bug fixes (features could also appear here if judged stable enough).

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

On 14/11/13 01:37, Tyro[17] wrote:
> Major releases (2.0)
>      The big ones, every six months, intended to ship in distributions and to be
> used by stability-oriented users.
>
> Release Candidates (2.065rc1)
>      Created one to two weeks before the release branch is created, this is a
> preview of the major release. There should be very few, if any changes from the
> release candidate to the major release.
> Bugfix releases (2.064.1)
>      Based on the previous major release or bugfix; contains only bugfixes and
> perhaps documentation corrections.
>
> Beta release (2.065beta1)
>      Created monthly from master, except for those months in which we create a
> major release. Stable and suitable for users who want the latest code and can
> live with changes from month to month.
>
> Your thoughts and concerns please.

** 1 **
It might be a good idea to consider this from an alternate angle -- different user needs.  You can probably divide these into three groups:

    (1) I want stability above all, no updates, only bugfixes.

    (2) I want to receive new non-breaking functionality as well as bugfixes.

    (3) I want bleeding-edge everything, I can cope with backwards-incompatible
        changes.

It's not clear to me how (2) is addressed in your proposal.  What guarantees are made about the beta releases and backwards compatibility?  Can we assume that with beta releases breaking changes are always a possibility?

I imagine it may be difficult to separate out breaking and non-breaking new functionality in DMD development, so I can understand if you just want to support (1) and (3).


** 2 **
Is this proposal for DMD only, or does it include druntime and Phobos?  Either way there needs to be some consideration that druntime and Phobos need different approaches from DMD itself.  For Phobos in particular there seems to me to be much more short-term need for new functionality which does _not_ include breaking changes.


** 3 **
What's the plan for interacting with downstreams (GDC, LDC and potentially others)?  A 1-month beta turnaround may be too fast for them to do the work of integrating new releases; 6 months is an awfully long time to wait for updates.

Speaking as one who relies on the speed of the executables they produce, I would be quite upset if I had to wait 6 months for Phobos updates with these compilers -- it's already been frustrating enough as it is having to wait 3+ months for them to get Phobos bugfixes that I've provided.

On 15/11/13 00:36, Nick wrote:
> So all the passionate D devs here get their monthly releases

I would imagine many of the passionate D devs here are already running git HEAD -- 1 month is FAR too long to wait ... :-)

On 15/11/13 08:50, Jacob Carlborg wrote:
> The opposite of an LTS release is _not_ a beta release. It's a regular release.
> It seems it would be better if the beta release were regular releases and the
> releases were LTS releases.
>
> I'm having a hard time requiring my users to use anything that is not a release
> (that is, a beta).

Really this is a question of semantics and what usage patterns you want to encourage.  If you call something beta (or testing) you probably discourage a lot of people from using it -- that may be a good thing.

As far as I can see the _real_ distinction between the 1- and 6-month releases here is less about how bug-free the code is and more about how long you can expect to wait before potentially getting hit with a breaking change.

On Tuesday, November 19, 2013 11:40:18 Joseph Rushton Wakeling wrote:
> On 15/11/13 00:36, Nick wrote:
> > So all the passionate D devs here get their monthly releases
> 
> I would imagine many of the passionate D devs here are already running git HEAD -- 1 month is FAR too long to wait ... :-)

Well, if you're working on the code, you pretty much _have_ to be running on git HEAD - though what you use for your projects outside of working on dmd/druntime/Phobos is another matter.

I usually do even my own stuff with git HEAD, but I do have one project that's sitting on 2.059, because it hasn't worked on anything since (due to an ICE IIRC) - though once I get time to finish refactoring it, I expect that that won't be a problem anymore, because it'll have been almost completely rewritten.

- Jonathan M Davis