i see..
well: Specs:
Windows7 x64
ZTEX 1.15x   (1x)

Used a prebuilt windows binary.

Is the 1.15y supported by this? If not i could offer u remote access to one (windows, but i can setup linux aswell if u need it).

Ill be waiting I'm not a linux pro (somehow linux hates me ) but i can do basic things with it. In case u need to look for yourself i can offer Temvierwer ecess to it (and all the other 1.15x Boards; but i could separate them in a different VM if needed)

Unfortunately, I'm pretty sure this would have to either be variance, or driver-related. The only change I can think of that would have made any difference for GPUs, is dynamically loading the OpenCL.DLL rather than a normal dynamic link (this is why FPGA-only rigs can run the Windows binaries).

No, this release is based on CGMiner 2.3.4. I plan to merge Con's latest improvements into our git tree soon.

You should be able to ignore it unless you want GPUs mining.

If CGMiner "leapfrogs" by including all the fixups and enhancements in BFGMiner, then there'd be no reason to continue BFGMiner. The main reason BFGMiner exists is because CGMiner is not willing to include many necessary changes.

CGMiner has for the most part been a one-man show up until very recently. Kano added his API, but intentionally maintains it independently from CGMiner. I hopped on to refactor CGMiner for modular driver and FPGA support because I didn't want to be stuck using Ufasoft with my BitForce Single. I was also given an Icarus for the purpose of improving support for it. However, as of recently, Kano insists on continually breaking and undoing fixes I've made to the Icarus driver and refuses to learn how to develop as a team (eg, merging instead of overwriting others' changes), and Con seems content with him doing so. Therefore, forking in this scenario is better for miners who need reliable Icarus (and who knows what else in the future) support. If the scenario changes significantly, the conclusion may change too.

Edit: In short, I would prefer NOT maintaining a fork, but it sure beats spending hours arguing with Kano and eventually ending up with an unreliable miner due to my fixes being rejected.

You do, when you choose what miner you use. Since CGMiner doesn't include the changes I consider necessary as a miner, my choices are to stick with what I get, or fork and make it work myself. As a programmer, I chose the latter.

plz don't stop maintaining cgminer. i love it. the only thing i would change about it is to add the option to mine with cpu.

After 4h of sleeping i finally got somme time to sit with my brand new ztex "Y"
For last rew months here i was using cgminer 2.0.6 with 2x5870 (prebuilt) and now, i cant remeber haw to buit bfgminer on my own. I`m following README guide, but just like before - linux hates me too :/

i downloaded .zip, so ok, it`s not git.... ok... but:

any help here ??
ubuntu  11.04 10.10, sdk 11.6, sdk 2.4 - working perfectly with phoenix and cgminer 2.0.6

Firstly the TL;DR version: I consider it unlikely for a project run by Luke-jr to continually spit out reliable code
That may mean that you wont have any problems so it may not matter to you.

The long version:
The base code in cgminer is the scheduling and threading of dealing with mining devices and pools
That was designed and written by ckolivas - who also wrote a linux kernel scheduler that eventually led to the linux kernel 'gurus' rewriting their's coz ckolivas was better.

The FPGA code in cgminer is not really that big a deal.
Anyone can write that - hell - even I can
Adding support for the latest greatest patch by 'Luke-jr' is rarely if EVER going to mean you will get more BTC than pico bit cents.
Of course getting those extra pico bit cents is good - but in my case, I'm more wary of bugs going into the code first then the pico bit cent gains can go in next when it's tested and debugged

There is definitely no problem with arguing about opinions.
My problem came when luke-jr argues about bugs being bugs due to the "I'm always right" issue he has.

I wrote changes for Icarus but hadn't tested them on Windows so I didn't put them up for a pull request
Xiangfu and I ran that code for a few weeks that I had discussed often in IRC also (but I didn't do a pull request as I said a few times in IRC coz I had no working Windows test environment to compile or run it)

Luke-jr submitted a pull request to ckolivas to do the same thing weeks after I wrote it and had it in my git

In my first look at the code there were 2 bugs (from simply just looking at the code) that I brought up with Luke-jr
I knew they were bugs because I had already written my own version of the code (as he knew)
That turned into a long running argument of him saying they weren't bugs and that I was wrong
Nowhere in that first discussion did he consider testing what I pointed out or consider that what I said was correct.

I was correct, they were bugs and he eventually changed it (not the end of the bugs ... read below)

The reason I ended up outright rejecting his Icarus code, and writing mine over it, was the Windows issue:
I finally did get my windows environment working again by deleting it and starting again using Sharky's windows script
(which I hadn't wanted to do but obviously was necessary since I was taking way to long to fix my windows test area for cgminer)
Next, I firstly tried to run Luke-jr's Icarus code since it was ALREADY committed into cgminer (and DIRECTLY admitted by him already that he had never tested it on windows)
His version just hanged cgminer in windows (stopped dead mid code and didn't report an error or exit or abort)
I tried my version (2nd) and found that it failed to detect the icarus (and the code said so) then of course said it found nothing to mine with and exited.
What this of course meant was the initial detection code had an issue and I next implemented changes like af_newbie had suggested to initialise the Serial-USB and found that fixed it.
That didn't fix Luke-jr version (that was already committed into cgminer) so I wasn't really all that interested in debugging his code (and having another argument with him about whatever the bug was), his code that he hadn't even tested in windows (as he had stated himself) so since my code worked and I had written it weeks before and run it for weeks on 43 Icarus devices in linux - I simply requested my pull request be committed directly into cgminer (effectively undo luke-jr's changes) since the current code in there didn't even work on windows and hung cgminer

I'm not sure what anyone else would have done, but after the issue with him the week before arguing about him saying the text saying "ICA" instead of "PGA" being a MAJOR BUG and he wouldn't agree to anything that he said he would agree to about that text, I was jack of it and just overwrote his non-working icarus code (that I had myself written weeks before him anyway)

What this fork will have is "He is always right" so he will allow any code he writes even if he hasn't tested it properly (or tested it at all)
If he says "no that won't happen any more" then why the fuck did it happen OFTEN before - and how has that suddenly changed when no one else is checking his code?

Lastly, you don't need to believe me - but I can supply IRC logs and pull request logs that clearly show all this.
(I'm just not really interested in spending hours to go through all that - though the pull requests are all there for anyone to see and the irclog of Freenode/#cgminer - well yeah I have a majority of the last 8 months of that ...)

Aw, come on, do a proper release post.
If it's just 'cgminer' go read the release over there, then it's pretty much ... and go use cgminer also