www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - openrj.d resurrected

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
First time killed in June 2010 by Andrei Alexandrescu:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/dmd_1.062_and_2.047_release_18676.html#N18678

But openrj doesn't go down without a fight!

Another brave attempt at putting the beast to its misery, this time by
Sean Kelly in late December 2010:
http://www.digitalmars.com/d/archives/digitalmars/D/std.openrj_125471.html

But openrj strikes back and survives!

I say we nuke it from orbit, it's the only way to be sure.

Btw, I think I know what's going on. Even though it's not in the repo,
it's still distributed in the zip file (it's in 2.053 and every
earlier release). So someone who is packing the zip file must be
including the module by accident.
May 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2011 8:11 PM, Andrej Mitrovic wrote:
 Btw, I think I know what's going on. Even though it's not in the repo,
 it's still distributed in the zip file (it's in 2.053 and every
 earlier release). So someone who is packing the zip file must be
 including the module by accident.
Ok, I zapped it with prejudice.
May 28 2011
parent reply Brad Roberts <braddr puremagic.com> writes:
On 5/28/2011 11:36 PM, Walter Bright wrote:
 On 5/28/2011 8:11 PM, Andrej Mitrovic wrote:
 Btw, I think I know what's going on. Even though it's not in the repo,
 it's still distributed in the zip file (it's in 2.053 and every
 earlier release). So someone who is packing the zip file must be
 including the module by accident.
Ok, I zapped it with prejudice.
By changing your build process to start with an empty directory for each release?
May 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2011 11:45 PM, Brad Roberts wrote:
 On 5/28/2011 11:36 PM, Walter Bright wrote:
 On 5/28/2011 8:11 PM, Andrej Mitrovic wrote:
 Btw, I think I know what's going on. Even though it's not in the repo,
 it's still distributed in the zip file (it's in 2.053 and every
 earlier release). So someone who is packing the zip file must be
 including the module by accident.
Ok, I zapped it with prejudice.
By changing your build process to start with an empty directory for each release?
Nope. Simply deleted it.
May 29 2011
parent reply Brad Roberts <braddr puremagic.com> writes:
On 5/29/2011 12:11 AM, Walter Bright wrote:
 On 5/28/2011 11:45 PM, Brad Roberts wrote:
 On 5/28/2011 11:36 PM, Walter Bright wrote:
 On 5/28/2011 8:11 PM, Andrej Mitrovic wrote:
 Btw, I think I know what's going on. Even though it's not in the repo,
 it's still distributed in the zip file (it's in 2.053 and every
 earlier release). So someone who is packing the zip file must be
 including the module by accident.
Ok, I zapped it with prejudice.
By changing your build process to start with an empty directory for each release?
Nope. Simply deleted it.
You really ought to rework your build/release process to deal with an empty starting point. It's far more repeatable and reliable. This sort of problem will happen every time a file is removed or renamed. As history has shown more than once. :)
May 29 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/29/11 2:18 AM, Brad Roberts wrote:
 On 5/29/2011 12:11 AM, Walter Bright wrote:
 On 5/28/2011 11:45 PM, Brad Roberts wrote:
 On 5/28/2011 11:36 PM, Walter Bright wrote:
 On 5/28/2011 8:11 PM, Andrej Mitrovic wrote:
 Btw, I think I know what's going on. Even though it's not in the repo,
 it's still distributed in the zip file (it's in 2.053 and every
 earlier release). So someone who is packing the zip file must be
 including the module by accident.
Ok, I zapped it with prejudice.
By changing your build process to start with an empty directory for each release?
Nope. Simply deleted it.
You really ought to rework your build/release process to deal with an empty starting point. It's far more repeatable and reliable. This sort of problem will happen every time a file is removed or renamed. As history has shown more than once. :)
I agree... and I'm glad we're at a point in history where continuing to improve our teamwork and deployment practices becomes vital. Speaking of which, it would be great if pull requests enjoyed a larger participation. Pull request authors are very important to the future of D, and improving the time to acceptance would work greatly towards encouraging them and towards attracting others. Andrei
May 29 2011