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 v
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 i
On 11/13/13 4:37 PM, Tyro[17] wrote:
I'm of the opinion, however, that
the cycle should be six months long. This particular schedule is not of my own
crafting but I
believe it to be sound and worthy of emulation:
I think 6 months between releases is entirely too long. I'd really like us to be
On Thursday, 14 November 2013 at 02:47:15 UTC, Brad Roberts wrote:
I think 6 months between releases is entirely too long. I'd
really like us to be back closer to the once every month or two
rather than only twice a year. The pace of change is high and
increasing (which is a good thing). Rel
On 11/13/13, 9:46 PM, Brad Roberts wrote:
On 11/13/13 4:37 PM, Tyro[17] wrote:
I'm of the opinion, however, that
the cycle should be six months long. This particular schedule is not
of my own crafting but I
believe it to be sound and worthy of emulation:
I think 6 months between releases is en
On Thursday, 14 November 2013 at 03:03:14 UTC, Brad Anderson
wrote:
On Thursday, 14 November 2013 at 02:47:15 UTC, Brad Roberts
wrote:
clip
6 months between releases means a regression that was
introduced in the latest version requires you to wait another 6
months for the fix which means you
On 11/13/13, 10:03 PM, Brad Anderson wrote:
On Thursday, 14 November 2013 at 02:47:15 UTC, Brad Roberts wrote:
I think 6 months between releases is entirely too long. I'd really
like us to be back closer to the once every month or two rather than
only twice a year. The pace of change is high a
On 11/13/13 7:13 PM, Tyro[17] wrote:
On 11/13/13, 9:46 PM, Brad Roberts wrote:
On 11/13/13 4:37 PM, Tyro[17] wrote:
I'm of the opinion, however, that
the cycle should be six months long. This particular schedule is not
of my own crafting but I
believe it to be sound and worthy of emulation:
I
On 11/14/13, Brad Anderson wrote:
> 6 months between releases means a regression that was introduced
> in the latest version requires you to wait another 6 months for
> the fix which means you are running a version that is a year out
> of date.
6 months is ridiculously long. The changelog itself
On 11/13/13, 11:06 PM, Brad Roberts wrote:
On 11/13/13 7:13 PM, Tyro[17] wrote:
On 11/13/13, 9:46 PM, Brad Roberts wrote:
On 11/13/13 4:37 PM, Tyro[17] wrote:
I'm of the opinion, however, that
the cycle should be six months long. This particular schedule is not
of my own crafting but I
believe
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.
[...]
At four-week intervals we make a new beta release. There will
be no separate releas
On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
On 11/14/13, Brad Anderson wrote:
6 months between releases means a regression that was introduced
in the latest version requires you to wait another 6 months for
the fix which means you are running a version that is a year out
of date.
6 months i
On Thursday, 14 November 2013 at 05:05:39 UTC, Tyro[17] wrote:
On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
On 11/14/13, Brad Anderson wrote:
6 months between releases means a regression that was
introduced
in the latest version requires you to wait another 6 months
for
the fix which means y
On 2013-11-14 01:37, Tyro[17] wrote:
Your thoughts and concerns please.
I like that you're doing this. But as others have said, I think the
release schedule is too long. Iain has already been complaining several
times that the releases is taking too long time. It gets hard them to
merge the
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.
... (clip) ...
Your thoughts and con
On 14.11.2013. 5:29, Tyro[17] wrote:
> On 11/13/13, 11:06 PM, Brad Roberts wrote:
>> On 11/13/13 7:13 PM, Tyro[17] wrote:
>>> On 11/13/13, 9:46 PM, Brad Roberts wrote:
On 11/13/13 4:37 PM, Tyro[17] wrote:
> I'm of the opinion, however, that
> the cycle should be six months long. This p
On Thursday, 14 November 2013 at 08:03:40 UTC, Jacob Carlborg
wrote:
On 2013-11-14 01:37, Tyro[17] wrote:
Your thoughts and concerns please.
I like that you're doing this. But as others have said, I think
the release schedule is too long. Iain has already been
complaining several times that
On Thursday, 14 November 2013 at 08:03:40 UTC, Jacob Carlborg
wrote:
On 2013-11-14 01:37, Tyro[17] wrote:
Your thoughts and concerns please.
I like that you're doing this. But as others have said, I think
the release schedule is too long. Iain has already been
complaining several times that
On Thursday, 14 November 2013 at 08:39:36 UTC, luka8088 wrote:
Also vote up for daily snapshots.
Ack.
Ultimately, I could envision a mostly automated release
management:
1. Nightly builds aka alpha versions (auto)
2. Nightly builds which pass testsuite = beta versions (auto)
3. Declare majo
On Thursday, November 14, 2013 10:18:08 qznc wrote:
> The 6 month cycle for *major* releases, means 6 months until a
> release which might break your code. Less for minor bug fix
> releases.
It's fallacy to think that bug fixes are less likely to break code. In fact,
based on dmd's history, I bel
On 2013-11-14 09:39, luka8088 wrote:
Just a wild thought...
Maybe we can have monthly release and still keep it stable. Imagine this
kind of release schedule:
Month # 11 12 1 2 3
2.064 2.065 2.066 2.067 2.068
2
Am 14.11.2013 06:05, schrieb Tyro[17]:
> On 11/13/13, 11:30 PM, Andrej Mitrovic wrote:
>> On 11/14/13, Brad Anderson wrote:
>>> 6 months between releases means a regression that was introduced
>>> in the latest version requires you to wait another 6 months for
>>> the fix which means you are runni
On 2013-11-14 10:02, growler wrote:
Would this still be a problem though if GDC and LDC align to the beta
release schedule?
I would guess so. The problem is that the longer we wait the more code
will have change, which means harder to merge with GC and LDC. Unless
they continuously merge.
On Thursday, 14 November 2013 at 05:05:39 UTC, Tyro[17] wrote:
It's been approximately six months since the release of 2.063
(alright five+: May 28 to Nov 5). I don't think too many of us
lost sleep over that. There is nothing ridiculously long about
six months.
I'm not using HEAD either and
On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
...
Your thoughts and concerns please.
Key problem here is that you call by beta something that is
really not a beta. It is short term support release similar to
ones we currently have with a shorter release schedule. And if it
On 11/14/13, Sönke Ludwig wrote:
> Just a little personal impression - it seems like during 2.064's
> development, more people than ever have switched to DMD HEAD instead of
> the last release version. This made it much more burdensome to support
> public libraries, because compiler induced breaka
On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
[...]
Your thoughts and concerns please.
Please do not mix together bugs fix releases with enhancement/new
addition releases, those represent two different types of release
that serve two entirely different purposes.
Bug fixes s
On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
Bug fixes should be as frequent as possible. To understand why,
just try and find a good reason to artificially hold back a bug
fix.
Code breakage. DMD has good amount of accepts-invalid bugs.
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 i
On Thursday, 14 November 2013 at 20:30:40 UTC, Dicebot wrote:
On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
Bug fixes should be as frequent as possible. To understand
why, just try and find a good reason to artificially hold back
a bug fix.
Code breakage. DMD has good amount of
On Thursday, 14 November 2013 at 20:53:05 UTC, deadalnix wrote:
...
Hush-hush :) I was simply answering a question "Why may someone
refuse to move to minor release that contains only bug fixes".
Nothing more, nothing less, no hidden implications :)
Le 14/11/2013 09:39, luka8088 a écrit :
On 14.11.2013. 5:29, Tyro[17] wrote:
On 11/13/13, 11:06 PM, Brad Roberts wrote:
On 11/13/13 7:13 PM, Tyro[17] wrote:
On 11/13/13, 9:46 PM, Brad Roberts wrote:
On 11/13/13 4:37 PM, Tyro[17] wrote:
I'm of the opinion, however, that
the cycle should be si
I have no idea what everyone is getting worked up about. My
understanding of the plan is that there are biannual major
releases, with bug fix releases in-between, for those
people/companies who need stability/dependability.
In addition to that we have monthly 'beta' releases for those who
wan
On 11/14/2013 09:18 AM, tn wrote:
What is wrong with the process that is described in the wiki (and that I
thought you already agreed on)? See
http://wiki.dlang.org/Development_and_Release_Process
It's too complex.
On 11/15/2013 12:36 AM, Nick wrote:
I have no idea what everyone is getting worked up about. My
understanding of the plan is that there are biannual major releases,
with bug fix releases in-between, for those people/companies who need
stability/dependability.
In addition to that we have monthly
On Thursday, 14 November 2013 at 20:30:40 UTC, Dicebot wrote:
On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
Bug fixes should be as frequent as possible. To understand
why, just try and find a good reason to artificially hold back
a bug fix.
Code breakage. DMD has good amount of
On Friday, 15 November 2013 at 00:30:09 UTC, Martin Nowak wrote:
On 11/14/2013 09:18 AM, tn wrote:
What is wrong with the process that is described in the wiki
(and that I
thought you already agreed on)? See
http://wiki.dlang.org/Development_and_Release_Process
It's too complex.
How? It is
On 2013-11-15 02:33, Jesse Phillips wrote:
How? It is the same as Tyro[17] describes only with 2 month rather than
6 month releases. The page just goes into great detail about how to
achieve it, which is complex.
Yeah, it has all the git commands, you don't have to read those.
--
/Jacob Carlb
On 2013-11-15 00:36, Nick wrote:
I have no idea what everyone is getting worked up about. My
understanding of the plan is that there are biannual major releases,
with bug fix releases in-between, for those people/companies who need
stability/dependability.
In addition to that we have monthly 'be
tl;dr thread.
What about release circle as debian project have.
Stable (LTS) release, for example, each year or each 3 versions
with backports available.
Testing release, for example, each month.
Unstable (head revision), each week?
Naming:
dmd-2.065.0-2013.11.15-unstable.zip,
dmd-2.065.0-
On 14.11.2013. 10:55, Jacob Carlborg wrote:
> On 2013-11-14 09:39, luka8088 wrote:
>
>> Just a wild thought...
>>
>> Maybe we can have monthly release and still keep it stable. Imagine this
>> kind of release schedule:
>>
>> Month # 11 12 1 2 3
>>
>>
On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
Bugfix releases (2.064.1)
Based on the previous major release or bugfix; contains
only bugfixes and perhaps documentation corrections.
Your thoughts and concerns please.
Do you happen to work with me? We have two dozens of
On 15.11.2013. 0:22, Xavier Bigand wrote:
> Le 14/11/2013 09:39, luka8088 a écrit :
>> On 14.11.2013. 5:29, Tyro[17] wrote:
>>> On 11/13/13, 11:06 PM, Brad Roberts wrote:
On 11/13/13 7:13 PM, Tyro[17] wrote:
> On 11/13/13, 9:46 PM, Brad Roberts wrote:
>> On 11/13/13 4:37 PM, Tyro[17] w
On 2013-11-15 00:22, Xavier Bigand wrote:
There is a lot of development I am waiting for my project, I'll really
be happy to see one come before the next summer :
- std.logger
- std.serialization
- Weak Ptr
- New signals/slots
- RPC (Remote procedure call)
- AST Macro
I'm wondering
On 2013-11-15 10:16, luka8088 wrote:
Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and
fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1
that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0.3.1.
There's a difference in still supporting old re
On Friday, November 15, 2013 11:03:37 Jacob Carlborg wrote:
> On 2013-11-15 00:22, Xavier Bigand wrote:
> > There is a lot of development I am waiting for my project, I'll really
> >
> > be happy to see one come before the next summer :
> > - std.logger
> > - std.serialization
> > - Weak Ptr
On 15.11.2013. 11:01, Jacob Carlborg wrote:
> On 2013-11-15 10:16, luka8088 wrote:
>
>> Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and
>> fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1
>> that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0
On 2013-11-15 11:51, luka8088 wrote:
I think API change could be analog to features change (and the way they
are interfaced).
So the version consists of x.y.z
z increments only on bug fixes.
y increments when new features are added, but they are backwards
compatable. Incrementing y resets z to
On Friday, 15 November 2013 at 09:17:45 UTC, ponce wrote:
Do you happen to work with me? We have two dozens of such
releases branch :) And customers still tend to prefer the
slightly bleeding edge ones.
While this effectively _does_ work in creating more stable
releases, I think that it puts
I'm having a hard time requiring my users to use anything that
is not a release (that is, a beta).
The point is, there has never been a really stable dmd release.
Using it requires to read the mailing list just like with most
beta software.
We won't be able to release a stable compiler every mo
On 2013-11-15 14:06, Martin Nowak wrote:
The point is, there has never been a really stable dmd release.
Using it requires to read the mailing list just like with most beta
software.
We won't be able to release a stable compiler every month anytime soon.
True, but a beta would be even less sta
On Friday, 15 November 2013 at 09:23:27 UTC, luka8088 wrote:
Yes but not having a delay between the time a new feature is
implemented
and the time it is released is very risky in terms of bugs.
Because this
new features has not been tester properly. And that is a fact.
Common misconception. W
On Friday, 15 November 2013 at 12:58:47 UTC, Martin Nowak wrote:
That's the exact problem with most of the release ideas
proposed here, they are terribly inefficient.
The schedule proposed by Andrew only requires one maintenance
branch (point releases) besides the regular beta releases from
mas
On Friday, 15 November 2013 at 07:50:28 UTC, Jacob Carlborg wrote:
The opposite of an LTS release is _not_ a beta release. It's a
regular release. It seems it would be better if the beta
release were regular releases and the releases were LTS
releases.
I'm having a hard time requiring my user
On Friday, 15 November 2013 at 15:25:29 UTC, QAston wrote:
On Friday, 15 November 2013 at 07:50:28 UTC, Jacob Carlborg
wrote:
On the other hand, supporting build with 2 versions: latest
beta and latest LTS is not a big burden imo (unless you expose
bleeding edge features in the api).
I like
On Thursday, November 14, 2013 14:55:44 Dicebot wrote:
> On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> > ...
> >
> > Your thoughts and concerns please.
>
> Key problem here is that you call by beta something that is
> really not a beta. It is short term support release similar
On 14/11/13 01:37, Tyro[17] wrote:
Major releases (2.0)
The big ones, every six months, intended to ship in distributions and to be
used by stability-oriented users.
Release Candidates (2.065rc1)
Created one to two weeks before the release branch is created, this is a
preview of the ma
On 15/11/13 00:36, Nick wrote:
So all the passionate D devs here get their monthly releases
I would imagine many of the passionate D devs here are already running git HEAD
-- 1 month is FAR too long to wait ... :-)
On 15/11/13 08:50, Jacob Carlborg wrote:
The opposite of an LTS release is _not_ a beta release. It's a regular release.
It seems it would be better if the beta release were regular releases and the
releases were LTS releases.
I'm having a hard time requiring my users to use anything that is not
On Tuesday, November 19, 2013 11:40:18 Joseph Rushton Wakeling wrote:
> On 15/11/13 00:36, Nick wrote:
> > So all the passionate D devs here get their monthly releases
>
> I would imagine many of the passionate D devs here are already running git
> HEAD -- 1 month is FAR too long to wait ... :-)
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 i
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
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
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 wi
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 z
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
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 a
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 win
On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
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.
Rele
On Tuesday, 3 December 2013 at 20:51:27 UTC, Martin Nowak wrote:
On Tuesday, 3 December 2013 at 16:04:32 UTC, Dicebot wrote:
Wasn't Nick working on automation of that part?
https://github.com/D-Programming-Language/installer/pull/24
On Tuesday, 3 December 2013 at 16:04:32 UTC, Dicebot wrote:
Wasn't Nick working on automation of that part?
It isn't automatable because the zip is assembled from different
platforms.
On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
Tools currently included in the packages are as follows:
We need to discuss the list of included tools.
Some of them are only available as binaries, i.e. only Walter
knows how to build them. Also DUMPOBJ and OBJ2ASM aren't need
On Tuesday, 3 December 2013 at 21:23:49 UTC, Martin Nowak wrote:
The tools strictly related to D are, dman, ddmangle and rdmd.
And link on windows.
Thanks for doing this Andrew.
On 2013-12-03 21:51, Martin Nowak wrote:
It isn't automatable because the zip is assembled from different platforms.
Why can't that be automatable? We do have the servers running the tests.
The idea is that they should build them.
--
/Jacob Carlborg
On 12/3/13, 12:21 PM, tn wrote:> 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 ma
On 12/3/13, 2:08 PM, Brad Anderson wrote:
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 C
On 12/3/13, 3:32 PM, Nick wrote:
On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
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
On 12/3/13, 4:23 PM, Martin Nowak wrote:
On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
Tools currently included in the packages are as follows:
We need to discuss the list of included tools.
Some of them are only available as binaries, i.e. only Walter knows how
to build t
On Wednesday, 4 December 2013 at 02:15:23 UTC, Andrew Edwards
wrote:
http://wiki.dlang.org/Development_and_Release_Process.
This does not reflect how we handle things currently.
It would be good to start from the current process (version
branch +
cherry-picking from master) and incrementall
On 12/3/13, 9:26 PM, Jesse Phillips wrote:
On Wednesday, 4 December 2013 at 02:15:23 UTC, Andrew Edwards wrote:
http://wiki.dlang.org/Development_and_Release_Process.
This does not reflect how we handle things currently.
It would be good to start from the current process (version branch +
c
On 12/3/13, 9:15 PM, Andrew Edwards wrote:
On 12/3/13, 4:23 PM, Martin Nowak wrote:
Only Walter knows how to build the zip.
Nick wrote a build script the produces a similar zip file,
https://github.com/D-Programming-Language/installer/pull/24.
Maybe we can get that in shape for the next few rele
On Wednesday, 4 December 2013 at 04:29:19 UTC, Andrew Edwards
wrote:
On 12/3/13, 9:15 PM, Andrew Edwards wrote:
On 12/3/13, 4:23 PM, Martin Nowak wrote:
Only Walter knows how to build the zip.
Nick wrote a build script the produces a similar zip file,
https://github.com/D-Programming-Language/i
On 12/3/13, 11:29 PM, Andrew Edwards wrote:
I created the v2.065-b1 tag and verified that it actually exists. If I
use 2.065 as indicated in the instructions for making betas, it results
in the exact same error.
Any thoughts?
OK the problem was that I didn't finish branching all the componen
On 12/3/13, 11:38 PM, Craig Dillabaugh wrote:
On Wednesday, 4 December 2013 at 04:29:19 UTC, Andrew Edwards wrote:
On 12/3/13, 9:15 PM, Andrew Edwards wrote:
On 12/3/13, 4:23 PM, Martin Nowak wrote:
Only Walter knows how to build the zip.
Nick wrote a build script the produces a similar zip fi
On 2013-12-03 15:25, Andrew Edwards wrote:
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 rel
On 2013-12-04 03:26, Jesse Phillips wrote:
Also, at some point Walter said in a random forum post that he wanted
this next release to be bug fixes only and rather quick... You're plan
and Walter's don't seem to match exactly.
Walter has also said it's up to the release manager (build master) t
On 2013-12-03 20:08, Brad Anderson wrote:
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 doubt he has a completely automated process of doing it. It has failed
too many t
On 2013-12-04 02:30, Andrew Edwards wrote:
Ok, got you. One question, does dinstaller.nsi work on linux/osx? If not
I will need your assistance to prepare the package until such time as I
can obtain an image for VirtualBox.
Everything should be built using the autotester.
Which is basically
On 2013-12-04 05:29, Andrew Edwards wrote:
Tried it but came across the following errors:
andrews-mini:osx-release ace$ ~/create_dmd_release v2.065-b1
--extras=$HOME/localextras-osx --archive-zip --archive-7z
Cloning: g...@github.com:D-Programming-Language/dmd.git
The authenticity of host 'g
On 2013-12-04 06:25, Andrew Edwards wrote:
My next question is whether or not this can be used on my platform (OSX)
to build binaries for the other platforms (Linux, Windows, FreeBSD) or
do I have to be on those platforms to do so? If that is the case, then I
will need assistance getting for Win
On 12/4/13, 3:09 AM, Jacob Carlborg wrote:
On 2013-12-03 15:25, Andrew Edwards wrote:
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
On 12/4/13, 3:21 AM, Jacob Carlborg wrote:
On 2013-12-04 05:29, Andrew Edwards wrote:
Couldn't do git protocol, falling back to 'https://'...
You need to have your SSH key uploaded to github. See:
https://help.github.com/articles/generating-ssh-keys
I did this but it is not working for m
On 2013-12-04 09:23, Andrew Edwards wrote:
Working on that.
* Instruct the autotester to build the compiler, libraries, installers
and all tools for each platform based on the newly created tag
Will need access from Brad Roberts. Have yet to receive any kind of
response to date.
* Assemble
04-Dec-2013 12:23, Andrew Edwards пишет:
On 12/4/13, 3:09 AM, Jacob Carlborg wrote:
On 2013-12-03 15:25, Andrew Edwards wrote:
[snip]
* Generate the changelog from bugzilla. The overview/general information
should already be present in the changelog at this time
Will need help on this one.
On 12/4/13 12:18 AM, Jacob Carlborg wrote:
On 2013-12-03 20:08, Brad Anderson wrote:
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 doubt he has a completely automated pr
On 2013-12-04 20:28, Dmitry Olshansky wrote:
There is a tool for that. Nothing stellar but it does the job:
https://github.com/D-Programming-Language/tools/blob/master/changed.d
Great.
Also be sure to contact Andrej Mitrovic he is a mastermind behind nice
changelogs we had for the last coupl
On 2013-12-04 20:52, Brad Roberts wrote:
I'm not sure this is really a good goal any more. The overlap between
testing and releasing isn't as big as I originally thought. Add to that
that the very definition of what a release is is in question. The only
overlap that really exists is that ther
On Tuesday, 3 December 2013 at 22:24:45 UTC, Jacob Carlborg wrote:
Why can't that be automatable? We do have the servers running
the tests. The idea is that they should build them.
Conflating binaries for multiple platforms is the problem here.
1 - 100 of 114 matches
Mail list logo
