On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze
No - I just have got a normal dedicated web-server thingy for
On 06.11.2013 09:25, Alexander Bothe wrote:
On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote:
Note: I saw Alexander Bothe released an update to the parser
your release... ;)
Sure, there have been a couple of critical regression bugs in
Furthermore, I re-enabled the ufcs completion.
Rainer, I somehow really recommend to provide a more frequent
update the D_Parser.dll - just to provide a way to fix e.g.
issues without having to recompile/package/upload the entire
An automated build system which simply calls
already suffices. I could insert a push hook into the repo
executed then in order to inform the build system to do a
It also was possible to execute Unittests first, so in the
there are some regression bugs (as it happened just recently),
won't be distributed.
Finally, a small webserver providing the built dll (or a zip
of it) and
a check whether there's an update available will passively
the dll to all clients. Not to forget some security things
check or encryption etc.
Yeah, being able to get releases out more often, and having bug
fixes being tested in the field would be nice. But I think we
should not over-engineer things here.
Do you have a web-server that could do the compilation?
But well, just a very small infrastructure that allows us to
update software more often - a couple of hours ago I implemented
this new eponymous template syntax..and now you had to release
another VisualD to have it in there, right?
Also, the D_Parser.dll could be put into the AppData/Roaming
no admin rights are needed for a parser update.
The component being used by Visual D is a local COM server, I'm
not sure if it is good to have that in a user folder.
Okay, it's probably safer to let the user decide when to update