On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> Greetings,
>
> I have accepted the responsibility of preparing the builds for DMD and would like to engage in conversation about the way ahead.
[...]
> At four-week intervals we make a new beta release. There will be no separate release candidate, but if a serious problem is discovered we may do the next beta ahead of schedule or make a point release. There will be about five or six releases in that series.
[...]
> 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.

First congratulations! Appreciate your work on this.

For me, I do not really have the time to keep a local build up-to-date to get the latest changes on head. So I would really appreciate having a regular binary release that would give me the latest changes. Being able to schedule in and rely on the proposed monthly beta release would be a big help. Definitely +1 to that part of the proposal. If a daily snapshot could be created reliably then that might work. As long as I can get a regular binary to install.

Thanks

Joseph

On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
> On 11/14/13, Brad Anderson <eco@gnuk.net> wrote:
>> 6 months between releases means a regression that was introduced
>> in the latest version requires you to wait another 6 months for
>> the fix which means you are running a version that is a year out
>> of date.
>
> 6 months is ridiculously long. The changelog itself will have to span
> pages. And because a lot of people do not use DMD-head we'll end up
> with a ton of regressions that are only caught after a release is
> made. And people who want an important fix will have to wait 6 months
> for a release. New library features or modules will only be properly
> tested after a release, so that means potentially waiting 6 months
> with very little feedback.
>
> IMO 6 months is unacceptably long. We're not steering an oil rig here,
> D is supposed to be a speedboat.
>

It's been approximately six months since the release of 2.063 (alright five+: May 28 to Nov 5). I don't think too many of us lost sleep over that. There is nothing ridiculously long about six months.

I doubt your change log would be much longer because of time elapsed. Rather, it would be longer because more people had time to work with the betas and discover the problems contained therein and subsequently got them fixed.

What I am proposing is that you get a package every month. That should be enough time to ferry out any regression that may crop up. Use the betas on a monthly basis and you get to ride the bullet train.

-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

On Thursday, 14 November 2013 at 05:05:39 UTC, Tyro[17] wrote:
> On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
>> On 11/14/13, Brad Anderson <eco@gnuk.net> wrote:
>>> 6 months between releases means a regression that was introduced
>>> in the latest version requires you to wait another 6 months for
>>> the fix which means you are running a version that is a year out
>>> of date.
>>
>> 6 months is ridiculously long. The changelog itself will have to span
>> pages. And because a lot of people do not use DMD-head we'll end up
>> with a ton of regressions that are only caught after a release is
>> made. And people who want an important fix will have to wait 6 months
>> for a release. New library features or modules will only be properly
>> tested after a release, so that means potentially waiting 6 months
>> with very little feedback.
>>
>> IMO 6 months is unacceptably long. We're not steering an oil rig here,
>> D is supposed to be a speedboat.
>>
>
> It's been approximately six months since the release of 2.063 (alright five+: May 28 to Nov 5). I don't think too many of us lost sleep over that. There is nothing ridiculously long about six months.
>
> I doubt your change log would be much longer because of time elapsed. Rather, it would be longer because more people had time to work with the betas and discover the problems contained therein and subsequently got them fixed.
>
> What I am proposing is that you get a package every month. That should be enough time to ferry out any regression that may crop up. Use the betas on a monthly basis and you get to ride the bullet train.

Thanks for taking this on.

Monthly beta releases will be great. Please add them to the main download page as they come out.

On 2013-11-14 01:37, Tyro[17] wrote:

> Your thoughts and concerns please.

I like that you're doing this. But as others have said, I think the release schedule is too long. Iain has already been complaining several times that the releases is taking too long time. It gets hard them to merge the changes to GDC. I guess LDC has similar problems.

-- 
/Jacob Carlborg

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> Greetings,
>
> I have accepted the responsibility of preparing the builds for DMD and would like to engage in conversation about the way ahead.
>
> The first concern I have is about the build cycle.
>
> ... (clip) ...
>
> Your thoughts and concerns please.

What is wrong with the process that is described in the wiki (and that I thought you already agreed on)? See

http://wiki.dlang.org/Development_and_Release_Process

and specifically

http://wiki.dlang.org/Development_and_Release_Process#Release_Schedule

There the release interval is described to be approximately 2 months (which in my opinion is more reasonable in the current state of language developement).

On 14.11.2013. 5:29, Tyro[17] wrote:
> On 11/13/13, 11:06 PM, Brad Roberts wrote:
>> On 11/13/13 7:13 PM, Tyro[17] wrote:
>>> On 11/13/13, 9:46 PM, Brad Roberts wrote:
>>>> On 11/13/13 4:37 PM, Tyro[17] wrote:
>>>>> I'm of the opinion, however, that
>>>>> the cycle should be six months long. This particular schedule is not
>>>>> of my own crafting but I
>>>>> believe it to be sound and worthy of emulation:
>>>>
>>>> I think 6 months between releases is entirely too long.  I'd really
>>>> like
>>>> us to be back closer to the once every month or two rather than only
>>>> twice a year.  The pace of change is high and increasing (which is a
>>>> good thing).  Release early and often yields a smoother rate of
>>>> introducing those changes to the non-bleeding-edge part of the
>>>> community.  The larger the set of changes landing in a release the more
>>>> likely it is to be a painful, breaking, experience.
>>>
>>> Surely for those of us that live on the edge, it is fun to be able to
>>> use the latest and greatest.
>>> Hence the reason for monthly release of betas. Within a month
>>> (sometimes shorter) of any new feature
>>> being implemented in the language, you'll be able to download the
>>> binaries for your favorite distro
>>> and begin testing it.
>>>
>>> The side effect is that there is more time to flesh out a particular
>>> implementation and get it
>>> corrected prior to it being an irreversible eyesore in the language.
>>> You also have a greater play in
>>> the filing bug reports as to aid in minimizing the number of bugs that
>>> make it into the final release.
>>>
>>> Unlike us adventurers however, companies require a more stable
>>> environment to work in. As such, the
>>> six month cycle provides a dependable time frame in which they can
>>> expect to see only bugfixes in to
>>> the current release in use.
>>>
>>> I think this release plan is a reasonable compromise for both parties.
>>
>> Companies that don't want frequent changes can just skip releases, using whatever update frequency meets their desires.  Companies do this already all the time.  That only issue there is how long we continue to backport fixes into past releases.  So far we've done very minimal backporting.
>>
>>
> 
> And what I am proposing is that we start backporting to stable releases and with subsequent bugfix releases.
> 
> I'm also suggesting that for people interested in a more frequent release will have at least five, if not more, such releases (betas) prior to the official release. Live on the edge... use the beta. That's what we do now.
> 
> At the moment there's nothing that make dmd.2.064.2 any more bug free than its previously released counterparts. Very few people participated in the review of the betas which were released arbitrarily (when the time seemed right). We simply call on of those betas dmd.2.064.2 and moved on. It still has a slew of bugs and more are discovered daily as people start to finally use the so called  "release".
> 
> I'm saying we are go about it a little different. We get more people involved in the testing process by providing more frequent release of betas and getting much of the bugs identified fixed before designating a release. To me you get what your are after a faster turnaround on fixes (monthly). And the broader customer base gets a more stable product with less bugs.
> 

Just a wild thought...

Maybe we can have monthly release and still keep it stable. Imagine this kind of release schedule:

Month #  11          12          1           2           3

         2.064       2.065       2.066       2.067       2.068
         2.065rc2    2.066rc2    2.067rc2    2.068rc2    2.069rc2
         2.066rc1    2.067rc1    2.068rc1    2.069rc1    2.070rc1
         2.067b2     2.068b2     2.069b2     2.070b2     2.071b2
         2.068b1     2.069b1     2.070b1     2.071b1     2.072b1
         2.069alpha  2.070alpha  2.071alpha  2.072alpha  2.073alpha

Where new features are only added to alpha release. And bug fixes are added to all releases.

This way new bug fixes and new features would be released every month but there would be a 5 month delay between the time that feature A is added to the alpha release and the time feature A is propagated to the stable release. But during this period feature A would be propagated through releases and there would be plenty of opportunity to test it and clear it of bugs. I am not a fan of such delay but I don't see any other way new features could be added without higher risk of bugs.

Also vote up for daily snapshots.

On Thursday, 14 November 2013 at 08:03:40 UTC, Jacob Carlborg wrote:
> On 2013-11-14 01:37, Tyro[17] wrote:
>
>> Your thoughts and concerns please.
>
> I like that you're doing this. But as others have said, I think the release schedule is too long. Iain has already been complaining several times that the releases is taking too long time. It gets hard them to merge the changes to GDC. I guess LDC has similar problems.

Would this still be a problem though if GDC and LDC align to the beta release schedule?

On Thursday, 14 November 2013 at 08:03:40 UTC, Jacob Carlborg wrote:
> On 2013-11-14 01:37, Tyro[17] wrote:
>
>> Your thoughts and concerns please.
>
> I like that you're doing this. But as others have said, I think the release schedule is too long. Iain has already been complaining several times that the releases is taking too long time. It gets hard them to merge the changes to GDC. I guess LDC has similar problems.

I assume there still is the possibility of bug-fix-releases between the major releases?

The 6 month cycle for *major* releases, means 6 months until a release which might break your code. Less for minor bug fix releases.

The Linux kernel has an 8 week cycle, but they aim for forever-backwards-compatible.

On Thursday, 14 November 2013 at 08:39:36 UTC, luka8088 wrote:
> Also vote up for daily snapshots.

Ack.

Ultimately, I could envision a mostly automated release management:

1. Nightly builds aka alpha versions (auto)
2. Nightly builds which pass testsuite = beta versions (auto)
3. Declare major releases (manually)

The concept of release candidates is merely a social concept in my view. They are basically used to start a discussion for consensus and get manual processes like Release Notes rolling. This means there is a manual step between 2 and 3, which consists of "declare beta version 42 = release candidate 2".

On Thursday, November 14, 2013 10:18:08 qznc wrote:
> The 6 month cycle for *major* releases, means 6 months until a release which might break your code. Less for minor bug fix releases.

It's fallacy to think that bug fixes are less likely to break code. In fact, based on dmd's history, I believe that bug fixes are _more_ likely to break code than new features are.

- Jonathan M Davis