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. Presently, it is nonexistent. There is no rhyme or reason regarding when releases are produced. The v2.065 agenda (first attempt of its kind) suggests that the next release will occur sometime in March 2014. I'm of the opinion, however, that the cycle should be six months long.

You shouldn't pay much attention to the length of the recent release cycles.
The last two release cycles were abnormally long. Historically we had a release about once a month, then that extended to two months. In the last year the cycles became ridiculously long. It's been completely unplanned.

But ANY time period you choose would be better than the current situation.

On Tuesday, November 19, 2013 12:50:29 Don wrote:
> You shouldn't pay much attention to the length of the recent
> release cycles.
> The last two release cycles were abnormally long. Historically we
> had a release about once a month, then that extended to two
> months. In the last year the cycles became ridiculously long.
> It's been completely unplanned.
> 
> But ANY time period you choose would be better than the current situation.

Hmmm. So, 7 years would be better? ;)

In any case, we definitely should try and have more regular releases in the one to two month range rather than the really long gaps that we've been having lately.

- Jonathan M Davis

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.

> Your thoughts and concerns please.

Stalled?

From the preceding discussion, it is clear that the community desires both a swift release cycle and more stability. No one solution will appease the entire community. Therefore, I will take the middle ground. The way forward will be as follows:

	Official releases will occur on an 8 week basis. The third such release will be LTS. All LTS releases will be supported with back-ports of regressions and non-breaking changes (bug fixes only) until the next LTS release. Meaning that only LTS releases will be support by point releases. No new feature features will be introduced in a point release.

	Betas will be released four weeks after an official release. The intent is to afford a thorough review of all features introduced since the last official release and allot ample time to remedy any resulting regressions.

	Release candidates will follow naturally from Betas two weeks prior to an official release. Once a release candidate is published, no new features will be added.

The same schedule will apply to all components of the language (DMD, DRUNTIME, and PHOBOS) and any tools that are included in the release packages.

Tools currently included in the packages are as follows:

	Linux:
		DDEMANGLE
		DMAN
		DUMPOBJ
		OBJ2ASM
		RMDM

	OSX:
		DDEMANGLE
		DMAN
		DUMPOBJ
		OBJ2ASM
		RMDM
		SHELL

	Windows:
		DDEMANGLE.EXE
		DMAN.EXE
		DUMPOBJ.EXE
		LIB.EXE
		LINK.EXE
		MAKE.EXE
		RDMD.EXE
		REPLACE.EXE
		SHELL.EXE
		WINDBG.EXE (AND OTHER REQUIRED FILES)

This list, at the very least, should include DustMite but there are some other tools included in the tools repo on github that might belong here. (This will be considered for inclusion in future releases and will have no effect on release 2.065)

As I am not skilled at GitHub, I will be following the instructions/guidelines exactly as outlined here:

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

I am working on a MacMini running OS X v10.9. I have Ubuntu 13.10 Server loaded in VirtualBox and will be using Jordi Sayol's script to build packages for linux/Windows and Jacob Carlborg script for OSX.

Both of these scripts require an preexisting release zip and as of this moment, I am unaware of the steps to create that file. I will need some instructions on how to access and run the auto tester if that's what generates the zip or, if it's already automatically created, instructions on how to retrieve and stage it for the build.

I will be setting up a tag on github today for the first beta release of 2.065 (2.065-b1).

Request your corporation/support in ensuring a smooth process.

Andrew

On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
> From the preceding discussion, it is clear that the community desires both a swift release cycle and more stability. No one solution will appease the entire community. Therefore, I will take the middle ground. The way forward will be as follows:

 I support this. It is a good start and, if really needed and obvious, changes to the process could be performed later. But, it is quite nice and it is important to have it started.

 I would vote for maximum automation of the building process (ideally, a single command that will build up everything in a single shot).

>
> Tools currently included in the packages are as follows:
>
> 		RMDM

??? RDMD?

Should DUB be added, too?

On Tuesday, 3 December 2013 at 15:36:46 UTC, eles wrote:
> Should DUB be added, too?

Lets wait a bit until it stabilizes a bit before putting it into official package. At future least SDL addition comes to my mind.

On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
> Both of these scripts require an preexisting release zip and as of this moment, I am unaware of the steps to create that file. I will need some instructions on how to access and run the auto tester if that's what generates the zip or, if it's already automatically created, instructions on how to retrieve and stage it for the build.

Wasn't Nick working on automation of that part?

In general this sounds great. However:

On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
> Betas will be released four weeks after an official release.

Does this mean that a new release branch will be created at that point? I think it makes sense.

> Once a release candidate is published, no new features will be added.

Does this imply that new features are still added in beta phase? That does not fit well with creating the branch in the beginning of the beta phase.

My opinion:

I don't think new features should be added in beta phase. Instead it should be for bug fixing. When no known blocker bugs are left, a release candidate phase should be started. Relase candidate should be, as the name implies, a candidate for release. Thus, if no new critical bugs are found, then the release can be made in principle just by bumping the version number.

More important than defining when the actual releases are made, is to define when branching is done. It is easy to slip release date because of new bugs and that can then delay the next release (depending on how you implement the procedure). Instead, a new release branch should be branched from the master branch exactly every 8 weeks. That should be easy, since there are no such stability requirements as for actual releases. Whether the following stabilisation phase (betas + release candidates) lasts exactly 3 or 4 or 5 weeks is not that important as long as the quality of the release will be acceptable. The phase should last long enough that all blocker bugs are fixed. In this model the time between actual releases can vary a bit, but on average it will be exactly 8 weeks.

On Tuesday, 3 December 2013 at 16:04:32 UTC, Dicebot wrote:
> On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
>> Both of these scripts require an preexisting release zip and as of this moment, I am unaware of the steps to create that file. I will need some instructions on how to access and run the auto tester if that's what generates the zip or, if it's already automatically created, instructions on how to retrieve and stage it for the build.
>
> Wasn't Nick working on automation of that part?

I believe you are correct but I don't think it''s ready as yet.

On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
> [snip]
> I am working on a MacMini running OS X v10.9. I have Ubuntu 13.10 Server loaded in VirtualBox and will be using Jordi Sayol's script to build packages for linux/Windows and Jacob Carlborg script for OSX.

Please use windows/dinstaller.nsi for creating the installer on Windows.  linux/win/installer.nsi has some missing features and an issue with deleting the entire directory tree as part of a uninstallation pre-step that has caused problems for some people. I'm going to try to merge these two files to pick up some of the useful features Jordi has added but for the time being dinstaller.nsi is the proper one to use.

>
> Both of these scripts require an preexisting release zip and as of this moment

dinstaller.nsi defaults to a web-installer (it downloads dmd2.zip and others itself). As such, it doesn't require the dmd zip to be present in order to create the installer executable. It can optionally embed the zip in the installer but that hasn't been how it's been used historically.

If you open up dinstaller.nsi it should be fairly obvious how it all works with regard to updating it for a new release. Just change the version number at the top of the file and ensure the url to the dmd zip a bit further down is correct.

Have you arranged with Walter or Brad Roberts to get access to upload to the download server? I think the build master having the ability to do uploads is vital.

>, I am unaware of the steps to create that file.

I believe Nick's release tool can generate the release zip properly. https://github.com/D-Programming-Language/installer/pull/24 I really recommend looking at it. He spent a lot of time perfecting it.

> I will need some instructions on how to access and run the auto tester if that's what generates the zip or, if it's already automatically created, instructions on how to retrieve and stage it for the build.

Historically, Walter has created the release zips (just using the makefile, I believe). As far as I know, work hasn't begun on getting the autotester to roll releases.

>
> I will be setting up a tag on github today for the first beta release of 2.065 (2.065-b1).
>
> Request your corporation/support in ensuring a smooth process.
>

Good luck. Let me know if you have any questions or problems with the Windows installer script.

> Andrew