January 24, 2011
On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam@example.com> wrote:

> Walter Bright wrote:
>> David Wang wrote:
>>> Dear Walter,
>>>
>>> I went to the github and try to download the source, I found that
>>> the latest version on github is the old version.
>>>
>>> for example:
>>>
>>> druntime - Downloads: dmd-2.042
>>> Phobos -   Downloads: phobos-2.046
>>> DMD -      Downloads: dmd-2.046
>>>
>>> I think the actural latest version of D should be 2.051.
>>>
>>> Why github can not showing the 2.051 version(dmd, phobos,
>>> druntime, and so on.) ?
>>
>> I think it is because the tags were never done properly on svn, either.
>
> It's still possible to add the tags (see
> http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
> know the commits used for the releases. I guess there's
> no easy way to figure out which commits were used for the releases?
>

All source is included in the compiler.  It's simply a matter of doing a directory compare of the code against source control.  The date released should narrow it down to a manageable level.

I have done it in the past (http://www.dsource.org/projects/druntime/changeset/272)  In fact, it looks like I was the last one to tag druntime :)

Some script-fu could probably fill in all the holes automatically...

-Steve
January 24, 2011
Steven Schveighoffer wrote:
>On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam@example.com> wrote:
>
>> Walter Bright wrote:
>>> David Wang wrote:
>>>> Dear Walter,
>>>>
>>>> I went to the github and try to download the source, I found that the latest version on github is the old version.
>>>>
>>>> for example:
>>>>
>>>> druntime - Downloads: dmd-2.042
>>>> Phobos -   Downloads: phobos-2.046
>>>> DMD -      Downloads: dmd-2.046
>>>>
>>>> I think the actural latest version of D should be 2.051.
>>>>
>>>> Why github can not showing the 2.051 version(dmd, phobos,
>>>> druntime, and so on.) ?
>>>
>>> I think it is because the tags were never done properly on svn, either.
>>
>> It's still possible to add the tags (see
>> http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
>> know the commits used for the releases. I guess there's
>> no easy way to figure out which commits were used for the releases?
>>
>
>All source is included in the compiler.  It's simply a matter of doing a directory compare of the code against source control.  The date released should narrow it down to a manageable level.
>
>I have done it in the past (http://www.dsource.org/projects/druntime/changeset/272)  In fact, it looks like I was the last one to tag druntime :)
>
>Some script-fu could probably fill in all the holes automatically...
>
>-Steve

OK, here are some revisions:
DMD:
2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
  Note: The changelog on the website says release date Nov 7 but it's
  more like 20th December.
  Note2: The git repository contains a object.h file in that revision
  which isn't in the dmd zip.
2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
  Note: The git repository contains a argtypes.c file in that revision
  which isn't in the dmd zip.
2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
  Note: In the dmd zip, there are 7 additional lines in
  root/root.c. Those were later added to the repository, but
  ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
  commit.

-- 
Johannes Pfau


January 24, 2011
Jonathan M Davis Wrote:

> If you grab the source with git, it's the latest version. I don't know how the downloads stuff works though - but as you say, it doesn't have the latest version. It will likely take some time to sort out all of the kinks of the transition though. From the looks of it, very few of the dmd/druntime/Phobos devs have experience with github.
> 
> - Jonathan M Davis

It looks like the downloads are generated off the tags. And since the tags aren't correct nor is the downloads.
January 24, 2011
== Quote from Johannes Pfau (spam@example.com)'s article
> --Sig_/hgUpRkpzV0eGcapavO0e/z1
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
> Steven Schveighoffer wrote:
...

> >All source is included in the compiler.  It's simply a matter of doing a directory compare of the code against source control.  The date released should narrow it down to a manageable level.
> >
> >I have done it in the past =20 (http://www.dsource.org/projects/druntime/changeset/272)  In fact, it =20 looks like I was the last one to tag druntime :)
> >
> >Some script-fu could probably fill in all the holes automatically...
> >
> >-Steve
> OK, here are some revisions:
> DMD:
> 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
>   Note: The changelog on the website says release date Nov 7 but it's
>   more like 20th December.
>   Note2: The git repository contains a object.h file in that revision
>   which isn't in the dmd zip.
> 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
>   Note: The git repository contains a argtypes.c file in that revision
>   which isn't in the dmd zip.
> 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
> 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
> 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
>   Note: In the dmd zip, there are 7 additional lines in
>   root/root.c. Those were later added to the repository, but
>   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
>   commit.

Someone might find this wiki page of use: http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=History/Year2010

It links to the release announcement for each version of DMD in 2010. (Earlier years are on other pages. I guess there hasn't been
a release in 2011 yet.)

I think the dates on this page are based on when the release announcement was sent rather than what the changelog might have. I'm
not sure which time zone was used (and it might be inconsistent), so it might be off a day compared to what you'd expect, but you
can look at the timestamp on Walter's messages by following the links.

Since it's a wiki, anyone can make corrections (or add more information) if they'd like to help.

jcc7
January 24, 2011
On Mon, 24 Jan 2011 10:34:18 -0500, Johannes Pfau <spam@example.com> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam@example.com>
>> wrote:
>>
>>> Walter Bright wrote:
>>>> David Wang wrote:
>>>>> Dear Walter,
>>>>>
>>>>> I went to the github and try to download the source, I found that
>>>>> the latest version on github is the old version.
>>>>>
>>>>> for example:
>>>>>
>>>>> druntime - Downloads: dmd-2.042
>>>>> Phobos -   Downloads: phobos-2.046
>>>>> DMD -      Downloads: dmd-2.046
>>>>>
>>>>> I think the actural latest version of D should be 2.051.
>>>>>
>>>>> Why github can not showing the 2.051 version(dmd, phobos,
>>>>> druntime, and so on.) ?
>>>>
>>>> I think it is because the tags were never done properly on svn,
>>>> either.
>>>
>>> It's still possible to add the tags (see
>>> http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
>>> know the commits used for the releases. I guess there's
>>> no easy way to figure out which commits were used for the releases?
>>>
>>
>> All source is included in the compiler.  It's simply a matter of doing
>> a directory compare of the code against source control.  The date
>> released should narrow it down to a manageable level.
>>
>> I have done it in the past
>> (http://www.dsource.org/projects/druntime/changeset/272)  In fact, it
>> looks like I was the last one to tag druntime :)
>>
>> Some script-fu could probably fill in all the holes automatically...
>>
>> -Steve
>
> OK, here are some revisions:
> DMD:
> 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
>   Note: The changelog on the website says release date Nov 7 but it's
>   more like 20th December.

That is probably a doc bug.  When creating the 'next' version in the changelog, Walter arbitrarily puts a date in there as a placeholder (usually the date he does that), and looks like he forgot to change it.  Probably we should get into the practice of putting TBD instead of a date.

>   Note2: The git repository contains a object.h file in that revision
>   which isn't in the dmd zip.
> 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
>   Note: The git repository contains a argtypes.c file in that revision
>   which isn't in the dmd zip.
> 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
> 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
> 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
>   Note: In the dmd zip, there are 7 additional lines in
>   root/root.c. Those were later added to the repository, but
>   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
>   commit.

At this point, I would say, tag those versions.  Its very unlikely that someone ever needs one of these old revs anyways.  I'm glad you were able to do all this work, thanks!

-Steve
January 24, 2011
"Johannes Pfau" <spam@example.com> wrote in message news:20110124163418.3880a154@jpf-Satellite-A100...
>
> OK, here are some revisions:
> DMD:
> 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
>   Note: The changelog on the website says release date Nov 7 but it's
>   more like 20th December.
>   Note2: The git repository contains a object.h file in that revision
>   which isn't in the dmd zip.
> 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
>   Note: The git repository contains a argtypes.c file in that revision
>   which isn't in the dmd zip.
> 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
> 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
> 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
>   Note: In the dmd zip, there are 7 additional lines in
>   root/root.c. Those were later added to the repository, but
>   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
>   commit.
>

Does Git really not have real revision/changeset numbers?


January 24, 2011
On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote:
> "Johannes Pfau" <spam@example.com> wrote in message news:20110124163418.3880a154@jpf-Satellite-A100...
> 
> > OK, here are some revisions:
> > DMD:
> > 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
> > 
> >   Note: The changelog on the website says release date Nov 7 but it's
> >   more like 20th December.
> >   Note2: The git repository contains a object.h file in that revision
> >   which isn't in the dmd zip.
> > 
> > 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
> > 
> >   Note: The git repository contains a argtypes.c file in that revision
> >   which isn't in the dmd zip.
> > 
> > 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
> > 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
> > 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
> > 
> >   Note: In the dmd zip, there are 7 additional lines in
> >   root/root.c. Those were later added to the repository, but
> >   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
> >   commit.
> 
> Does Git really not have real revision/changeset numbers?

It's SHA1 hashes. And actually, considering how prevalent branching and merging is with git (_everyone_ has their own fork of the repository), I question that revision/changeset numbers would work anyway. The fact that you can reorder commits wouldn't help either. So, no. Git doesn't have revision or changeset numbers.

However, the git commands where you give it a revision's SHA1 only need enough of the SHA1 to uniquely identify it, so you rarely need to type the whole thing even when you're giving it the SHA1. Now, I suppose that makes things like the revision number for dmd 2.049 uglier, but git is very much distributed and not centralized in terms of how it's set up, so revision numbers in the SVN sense just wouldn't make sense.

- Jonathan M Davis
January 24, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.911.1295903507.4748.digitalmars-d-announce@puremagic.com...
> On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote:
>> "Johannes Pfau" <spam@example.com> wrote in message news:20110124163418.3880a154@jpf-Satellite-A100...
>>
>> > OK, here are some revisions:
>> > DMD:
>> > 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
>> >
>> >   Note: The changelog on the website says release date Nov 7 but it's
>> >   more like 20th December.
>> >   Note2: The git repository contains a object.h file in that revision
>> >   which isn't in the dmd zip.
>> >
>> > 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
>> >
>> >   Note: The git repository contains a argtypes.c file in that revision
>> >   which isn't in the dmd zip.
>> >
>> > 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
>> > 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
>> > 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
>> >
>> >   Note: In the dmd zip, there are 7 additional lines in
>> >   root/root.c. Those were later added to the repository, but
>> >   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
>> >   commit.
>>
>> Does Git really not have real revision/changeset numbers?
>
> It's SHA1 hashes. And actually, considering how prevalent branching and
> merging
> is with git (_everyone_ has their own fork of the repository), I question
> that
> revision/changeset numbers would work anyway. The fact that you can
> reorder
> commits wouldn't help either. So, no. Git doesn't have revision or
> changeset
> numbers.
>
> However, the git commands where you give it a revision's SHA1 only need
> enough
> of the SHA1 to uniquely identify it, so you rarely need to type the whole
> thing
> even when you're giving it the SHA1. Now, I suppose that makes things like
> the
> revision number for dmd 2.049 uglier, but git is very much distributed and
> not
> centralized in terms of how it's set up, so revision numbers in the SVN
> sense
> just wouldn't make sense.
>

Not that I've actually used DVCSes much yet, but my understanding is that the same can be set of Hg and yet Hg handles revision/changeset numbers just fine. The nice things (plural) about those is that they're both readable and comparable.



January 24, 2011
Nick Sabalausky Wrote:

> Not that I've actually used DVCSes much yet, but my understanding is that the same can be set of Hg and yet Hg handles revision/changeset numbers just fine. The nice things (plural) about those is that they're both readable and comparable.

Here, how about a quote:

http://mercurial.selenic.com/wiki/RevisionNumber

"Pitfalls

"Revision numbers referring to changesets are very likely to be different in another copy of a repository. Do not use them to talk about changesets with other people. Use the changeset ID instead."

So I wouldn't really say that is "just fine."
January 24, 2011
On Monday, January 24, 2011 13:20:44 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.911.1295903507.4748.digitalmars-d-announce@puremagic.com...
> 
> > On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote:
> >> "Johannes Pfau" <spam@example.com> wrote in message news:20110124163418.3880a154@jpf-Satellite-A100...
> >> 
> >> > OK, here are some revisions:
> >> > DMD:
> >> > 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
> >> > 
> >> >   Note: The changelog on the website says release date Nov 7 but it's
> >> >   more like 20th December.
> >> >   Note2: The git repository contains a object.h file in that revision
> >> >   which isn't in the dmd zip.
> >> > 
> >> > 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
> >> > 
> >> >   Note: The git repository contains a argtypes.c file in that revision
> >> >   which isn't in the dmd zip.
> >> > 
> >> > 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
> >> > 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
> >> > 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
> >> > 
> >> >   Note: In the dmd zip, there are 7 additional lines in
> >> >   root/root.c. Those were later added to the repository, but
> >> >   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
> >> >   commit.
> >> 
> >> Does Git really not have real revision/changeset numbers?
> > 
> > It's SHA1 hashes. And actually, considering how prevalent branching and
> > merging
> > is with git (_everyone_ has their own fork of the repository), I question
> > that
> > revision/changeset numbers would work anyway. The fact that you can
> > reorder
> > commits wouldn't help either. So, no. Git doesn't have revision or
> > changeset
> > numbers.
> > 
> > However, the git commands where you give it a revision's SHA1 only need
> > enough
> > of the SHA1 to uniquely identify it, so you rarely need to type the whole
> > thing
> > even when you're giving it the SHA1. Now, I suppose that makes things
> > like the
> > revision number for dmd 2.049 uglier, but git is very much distributed
> > and not
> > centralized in terms of how it's set up, so revision numbers in the SVN
> > sense
> > just wouldn't make sense.
> 
> Not that I've actually used DVCSes much yet, but my understanding is that the same can be set of Hg and yet Hg handles revision/changeset numbers just fine. The nice things (plural) about those is that they're both readable and comparable.

I don't know. I haven't used Hg. However, I have a hard time seeing how you could have revision numbers like subversion does. You could certainly have numbers which weren't hashes or in base 16, but you can't just increment the version number each time, or you'll run into conflicts when you go to merge. Maybe the Hg guys figured out something smart that manages. I don't know. But git uses the SHA1 hash, which is supposedly unique and avoids any version numbers clashing. It also serves as a means of guaranteeing that your repository hasn't been damaged, since if the repo's state doesn't match its SHA1, then it's not valid (due to data corruption or tampering or whatever).

- Jonathan M Davis