On 8/19/14, 3:09 PM, Dicebot wrote:
> On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei Alexandrescu wrote:
>>> Walter, now that release is out can you please state your opinion about
>>> https://github.com/D-Programming-Language/dmd/pull/3651 ? It is blocking
>>> Phobos module split and decoupling.
>>
>> LGTM. Any opposition to merging? -- Andrei
>
> Walter seems to be the only one :)
> http://forum.dlang.org/post/lt00a9$2uoe$1@digitalmars.com

I think it would be great to motivate the change properly. -- Andrei

On Tue, 19 Aug 2014 15:27:34 -0700
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> I think it would be great to motivate the change properly. -- Andrei
aren't it motivated enough in PR? this will allow to build real package hierarchies instead of dumping everything in one flat package. my.package, my.package.internal, my.package.network, my.package.utils, etc. it's very convient and fits good in package system. we'll have modules, packages and package hierarchies, and everyone will be free to choose what he needs. modules for tiny projects, packages for small libraries, package hierarchies for big libraries (like phobos).

On Monday, 18 August 2014 at 23:18:46 UTC, Vladimir Panteleev wrote:
> On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
>> I also propose to start 2.067 beta branch right now and declare it yet another bug-fixing release.
>
> Isn't this what point-releases are for, though?

I agree, I think 2.066.next should be the focus considering the known issues of 2.066.

On Monday, 18 August 2014 at 20:43:44 UTC, Vladimir Panteleev wrote:
>
> How is it decided when it's time to cut off a new release? Do we have two RCs and that's it?

I find it hard to believe that it is just a coincidence that a surprise release occurred on the same day as Java 9 and C++14 announcements.

On Tuesday, 19 August 2014 at 22:27:28 UTC, Andrei Alexandrescu wrote:
> On 8/19/14, 3:09 PM, Dicebot wrote:
>> On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei Alexandrescu wrote:
>>>> Walter, now that release is out can you please state your opinion about
>>>> https://github.com/D-Programming-Language/dmd/pull/3651 ? It is blocking
>>>> Phobos module split and decoupling.
>>>
>>> LGTM. Any opposition to merging? -- Andrei
>>
>> Walter seems to be the only one :)
>> http://forum.dlang.org/post/lt00a9$2uoe$1@digitalmars.com
>
> I think it would be great to motivate the change properly. -- Andrei

I am not sure what can I add to what have been already said. To summarize:

Without this addition package.d is much less useful in practice - we can't separate existing modules into smaller packages without making almost all symbols public, not if at there is more there one level of nested packages in question. Dmitry needs it for splitting std.regex, it will be needed for std.meta, existing std.internal can actually become controlled by compiler instead of being undocumented convention.

And using more deeply nested module hiearchies with smaller modules is one of primary means for reducing internal Phobos dependencies and improving compile times that are currently lacking.

It is also 100% backwards compatible and does not introduce any new language concept being much less intrusive change than, for example, C++ namespace support recently added.

On 8/20/14, 8:38 AM, safety0ff wrote:
> On Monday, 18 August 2014 at 23:18:46 UTC, Vladimir Panteleev wrote:
>> On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
>>> I also propose to start 2.067 beta branch right now and declare it
>>> yet another bug-fixing release.
>>
>> Isn't this what point-releases are for, though?
>
> I agree, I think 2.066.next should be the focus considering the known
> issues of 2.066.

Fear not, point releases will address known deficiencies.

> On Monday, 18 August 2014 at 20:43:44 UTC, Vladimir Panteleev wrote:
>>
>> How is it decided when it's time to cut off a new release? Do we have
>> two RCs and that's it?
>
> I find it hard to believe that it is just a coincidence that a surprise
> release occurred on the same day as Java 9 and C++14 announcements.


Actually you can believe it. I am the one that called for the release and it pay ZERO attention to those two languages with the mild exception that when I have time I crack open a Java book to try to learn a little programming.

On Wednesday, 20 August 2014 at 00:14:59 UTC, Andrew Edwards wrote:
> On 8/20/14, 8:38 AM, safety0ff wrote:
>>
>> I agree, I think 2.066.next should be the focus considering the known
>> issues of 2.066.
>
> Fear not, point releases will address known deficiencies.
>

Btw, thank you for the good work you've done as release manager!

On 8/19/14, 1:26 PM, Andrei Alexandrescu wrote:
> On 8/18/14, 5:23 PM, Nick Sabalausky wrote:
>> On 8/18/2014 7:14 PM, Dicebot wrote:
>>>
>>> I also propose to start 2.067 beta branch right now and declare it yet
>>> another bug-fixing release.
>>
>> Seconded.
>
> Well that's what happened - someone started 2.067. What's the advantage
> of doing this? Now we need to worry about master and 2.067 instead of
> just master. -- Andrei
>

That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC.

Betas will be release 5 days apart. RCs will be released 3 days apart. If no regression is fixed during that beta/RC window, the window will be extended an additional 3/5 days (as appropriate) until either fixes are received or the review period ends: at which time the final release is prepared and published.

The only thing that will extend the review period is if a regression exiting at the time RC1 is released remains open at the end of the 8 weeks. At that time an additional week will be added to the release cycle to address those specific issues. If they cannot be addressed during that additional week, the cycle will be terminated and the final release published.

All regressions not addressed in the main release will be addressed in point releases. Point releases will be published in 2 week increments following the final release (as warranted).

Starting with 2.066, releases will be maintained for 1 year. Meaning, point releases will be published biweekly (as warranted) for 1 year after a major release. The only changes that will be pushed during point releases are known regressions and ICE.

To pull this off, I absolutely need the community's assistance. Issues must clearly indicate which version affected by a particular regression. A volunteer to help me track and categorize ice and regressions would do wonders.

Also, I need access to publish and upload to the s3 server. I cannot wait around on for files to be synched across servers or web pages to be updated with one word changes before I can take the next step, it is extremely time consuming and deteriorates productivity.

Note: there will normally be a 4 week break between release cycles. When a cycle is extended, the break will be reduced to 3 weeks. This particular cycle will start early because 2.066 ended 5 weeks after the planned release date.

Andrew

On Tuesday, 19 August 2014 at 11:12:25 UTC, Andrew Edwards wrote:
> [...]
> In essence, it was always this big, just you never saw it because it got downloaded during the installation process.

It was also significantly bigger before because the download it
did was the >30MB dmd zip that contained files for all platform,
not just Windows. The installer is LZMA compressed too so it's
even smaller than the dmd windows-only zip (16MB).

Because of this, download size is now 1/3rd what it was and
installation size dropped from 176 MB to just 71 MB.

On Wed, 20 Aug 2014 10:41:29 +0900
Andrew Edwards via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

btw. http://wiki.dlang.org/Beta_Testing contains bug #10928 as "blocker", but it's marked as "RESOLVED FIXED" in bugzilla. and bug #12696 needs to be rechecked, as it seems to be fixed too.

On 20/08/14 03:41, Andrew Edwards wrote:

> That was my doing... I am preparing myself for the next go around. The
> actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT)
> announcement. The beta cycle will run eight weeks following that. On the
> fourth week (22 Sept) I will transition from beta to RC.
>
> Betas will be release 5 days apart. RCs will be released 3 days apart.
> If no regression is fixed during that beta/RC window, the window will be
> extended an additional 3/5 days (as appropriate) until either fixes are
> received or the review period ends: at which time the final release is
> prepared and published.
>
> The only thing that will extend the review period is if a regression
> exiting at the time RC1 is released remains open at the end of the 8
> weeks. At that time an additional week will be added to the release
> cycle to address those specific issues. If they cannot be addressed
> during that additional week, the cycle will be terminated and the final
> release published.
>
> All regressions not addressed in the main release will be addressed in
> point releases. Point releases will be published in 2 week increments
> following the final release (as warranted).

I we're letting regressions through in the main release I'm wondering how likely they are to be fixed later.

> Starting with 2.066, releases will be maintained for 1 year. Meaning,
> point releases will be published biweekly (as warranted) for 1 year
> after a major release. The only changes that will be pushed during point
> releases are known regressions and ICE.
>
> To pull this off, I absolutely need the community's assistance. Issues
> must clearly indicate which version affected by a particular regression.
> A volunteer to help me track and categorize ice and regressions would do
> wonders.
>
> Also, I need access to publish and upload to the s3 server. I cannot
> wait around on for files to be synched across servers or web pages to be
> updated with one word changes before I can take the next step, it is
> extremely time consuming and deteriorates productivity.
>
> Note: there will normally be a 4 week break between release cycles. When
> a cycle is extended, the break will be reduced to 3 weeks. This
> particular cycle will start early because 2.066 ended 5 weeks after the
> planned release date.

All this should be written down somewhere in the wiki.

-- 
/Jacob Carlborg