> Greetings All
> 
> It has been 2 months since we had release 2.052. Just wondering when is the 2.053 release planned?

There isn't really a release schedule. A release kind of just happens when Walter decides that it's time or when someone else on the dev team (like Don) pushes for one.

Given the major changes that Don is currently making to CTFE, I wouldn't expect a release for a while. When he's likely to be done and those changes stable enough to be released, I don't know, but until they are, I wouldn't expect a release. I would guess that it'll be within the next month, but I don't know. I don't know how far along Don is. I do know that there are definite issues with the current state of dmd though, thanks to the fact that he's in the midst of making his changes.

> Also, is there an automated way to create a snapshot release from the git repositories?

You can download tagged releases, I believe, but that would be releases such as 2.052, not a random snapshot. The obvious thing to do is just use git to grab the source as it is now.

- Jonathan M Davis

Jonathan M Davis wrote:
>> Greetings All
>>
>> It has been 2 months since we had release 2.052. Just wondering when is the
>> 2.053 release planned?

> 
> There isn't really a release schedule. A release kind of just happens when Walter decides that it's time or when someone else on the dev team (like Don) pushes for one.

I'm about to push for one <g>. Normally, it's every two months.

> 
> Given the major changes that Don is currently making to CTFE, I wouldn't expect a release for a while. When he's likely to be done and those changes stable enough to be released, I don't know, but until they are, I wouldn't expect a release.

I'm only fixing regressions now. I've just made a pull request for the last ones which are open.

 I would guess that it'll be within the next month, but I
> don't know. I don't know how far along Don is. I do know that there are definite issues with the current state of dmd though, thanks to the fact that he's in the midst of making his changes.

I have another round of CTFE improvements planned, but I won't work on them until the next release. They won't be as disruptive to stability as these ones were. Basically, most of the infrastructure is in place now.

> Jonathan M Davis wrote:
> >> Greetings All
> >> 
> >> It has been 2 months since we had release 2.052. Just wondering when is the 2.053 release planned?
> > 
> > There isn't really a release schedule. A release kind of just happens when Walter decides that it's time or when someone else on the dev team (like Don) pushes for one.
> 
> I'm about to push for one <g>. Normally, it's every two months.

Well, then I'd better make sure that I get my most recent updates to std.datetime in soon.

- Jonathan M Davis

>
> Well, then I'd better make sure that I get my most recent updates to
> std.datetime in soon.
>
> - Jonathan M Davis

Does your library take into account that there's no year 0?

> > Well, then I'd better make sure that I get my most recent updates to std.datetime in soon.
> > 
> > - Jonathan M Davis
> 
> Does your library take into account that there's no year 0?

Actually, for ISO 8601, which the library follows, there _is_ a year 0. Date, DateTime, and SysTime all have the function yearBC which will give you the year as you would normally expect (1 B.C. being immediately prior to 1 A.D. with no year 0). But the ISO standard calls for a year 0, and I followed the standard (it's also way easier to deal with programmatically). So, other than the yearBC function, it treats 0 as the year prior to 1 A.D., and the years prior to 0 are negative.

- Jonathan M Davis

Ok, I was just making sure. I guess you would surely know about that.

I actually made a program that used date and time before your library. Not nice. I guess I should go and revisit it. I use the program of mine too, it boots with Windows.

On 22/04/2011 20:48, Jonathan M Davis wrote:
>>> Well, then I'd better make sure that I get my most recent updates to
>>> std.datetime in soon.
>>>
>>> - Jonathan M Davis
>>
>> Does your library take into account that there's no year 0?
>
> Actually, for ISO 8601, which the library follows, there _is_ a year 0.

And astronomers have used this year numbering scheme since the 17th century, apparently.

> Date,
> DateTime, and SysTime all have the function yearBC which will give you the
> year as you would normally expect (1 B.C. being immediately prior to 1 A.D.
> with no year 0). But the ISO standard calls for a year 0, and I followed the
> standard (it's also way easier to deal with programmatically). So, other than
> the yearBC function, it treats 0 as the year prior to 1 A.D., and the years
> prior to 0 are negative.

I think most calendar APIs would use 0, -1, -2, etc. to denote 1BC, 2BC, 3BC, etc. because it's by far the easiest thing for both library and library user to work with.  And leave to formatting features the task of turning them into BC/AD forms.  Look at how my library
http://pr.stewartsplace.org.uk/d/sutil/
deals with it.  (OK, so it only really manipulates dates in its own linear numbering scheme, but you get the idea.)

Stewart.