We could start a pool based on the V1.4 ship date with a nice prize.
Really though, Flex has delayed the release based on the major features that are being added and, no doubt, to fix several major pain points that still exist from V1.3.8 including DAX.
With the user base growing and the significant uptick in user feedback they want to ensure the best possible release which takes time and testing. I haven't heard them use the term (yet) of "Quality User Experience" but I believe that is what Flex will be going for in V1.4 and the following V1.5 (polishing release).
The worst possible scenario would be to release an update that breaks a significant functionality just to add features. Look at Microsoft, Apple and others. Even minor updates of theirs have gone wrong from time to time and they have "10 to umpteenth" more testers.
I think Gerald, Steve and Greg have done a good job of being honest with the Flex user base about the delay of V1.4 and stating their specific goals for V1.5. and DSP. Many companies spend significant $$$ on PR spin and additional promises. I prefer that the $$$ be spent on improving the product and the advances in the hobby that Flex is known for.
I also have great respect for all of the users that have software/hardware issues and come to the Community for help. The speed with which suggestions/answers are provided and the direct interaction by Flex employees makes this forum a significant benefit of being a Flex owner and certainly for prospective buyers.
Now about that pool....
Even though I have a 9 to 5 job, I am on the radio a lot. Even so, I still haven't completely explored all the options in the current 1.3.8 release. And when I do, there's still plenty of time for on the air fun, like getting into the Tromelin Island bloodbath.
I vote for letting the developers and the management of the company decide when the product is ready rather than rush it out before it's ready.
My coders always slipped unless they had a hard and fast drop deal deadline
Of course, when I tied a $$ bonus to finishing by the deadline, it was amazing how often they actually met that deadline... albeit sleep deprivation was part of their job description...
Steve H said there will be a new / updated road map coming out soon. Will they eliminate any reference to release dates? The new road map may give us a better idea of what to expect.
Thread on the V2.0 Road Map Update:
Hopefully the road map will still include the time dimension. Maybe just list the Quarter for a release. Or stick with the month and include a caveat that the date is not a commitment, just a general target. A road map without a time frame is not nearly as informative. I'm sure the folks waiting for V2.0 and WAN remote would like to know if it is more likely to be next summer or closer to Christmas 2015.
Regards, Al / NN4ZZ
al (at) nn4zz (dot) com
So shifting a month or so is will happen. I don't think knowing the exact release date is so important. But to know what they have planed and are working on is.
Remember, the most important thing is our input as a Flex community. The radio will only be as good as our post here. Many of us over time stumble on things that a bata tester may never find in the time they have. but we,,us,, put the radio through it's paces. How many times have I read here about flaws only found weeks after it's release.
It is much simpler for the big 3 to come out with new radios. They have been making them for how many years now? And they are not software driven, just a simple firmware to make it all work.
But for Flex it is new ground, new tech. And just think, we all have a part in it as it develops.
I can't think of when Icom or any of the other makers had there customers involved with the design and features of there radios. And had and have people who work there take questions from customers and comment daily to keep people informed as to the developments.
Just my 2 cents from a frustrated flex user.
It could allow Flex to square this particular circle.
It would mean building the test suite as they go (esp. unit test) but I hope they are already doing that as it is getting to be increasingly the industry standard for quality software. I've had particularly happy experiences with the Java version of that (Maven or Eclipse) as it is fully integrated with all compliations and builds. But nearly all languages now offer some form of this.
The thing with Agile is that even if the features aren't 100 per cent complete in terms of function, there will be, in every two week cycle, a shippable product. Now, I wouldn't expect them to actually ship every two weeks (for our sake and for support's sake) but the point is, as deadlines loom, there will be something coherent to deal with when the deadline is reached. They can, for instance, draw a line at some two week boundary or other, and enter final product test if that's what they need to do to deliver on time. Or, if they get really into it, just decide that a given version at the end of a sprint is ready to go as the integrated testing proves "good enough to ship" (this usually takes some effort over time). We users may see partial function here and there, but that's actually OK if the quality is there for what _is_ shipped. In some cases, in fact, the partial function will be all anyone wants!
That kind of solves, in one way, the dilemma between a hard deadline and shipping quality code. You much more often meet the deadline with quality work. Even if you miss, you can nearly guarantee delivery two weeks after that. You've done so by taking the extra time and effort to break implementations into bite sized, deliverable chunks, each with clean delivery criteria, complete with testing, so you can always deliver the rest later. It also tends to get rid of 'specification-itis' where you write a lot of code (Agile shows you this is so after you've done it a while) you don't actually need and consumers end up not actually wanting. This gets good code into consumers' hands faster. It also lets the software coders do what is really being asked for here; adjust to problems as they arise (nobody foresees half of what goes wrong) and still be able to have a coherent product which can almost always be shipped at the end of every sprint or at the end of the sprint that enters some sort of final product test.
It will be harder synching Agile with any new hardware, but as far as "pure software" goes, it seems, after two years of personal industry experience with it, a great way of delivering software. It takes some getting used to, and we as users may adjust a bit, too, but imagine having a "mostly working" remote experience right now, today, where you don't have everything working but what you do have works very well.
"I know that many of you are eagerly awaiting the new features in SmartSDRTM v1.4, which include LAN remote, FM, Memories, integrated FreeDV mode, open Waveform API, DAX enhancements and more. There is so much in this release that it is amazing what our team has accomplished in just ten weeks since v1.3 shipped. As in previous releases, we are incorporating more features and groundbreaking capabilities (e.g. Waveform API and FreeDV) than were originally promised in the SmartSDR roadmap.
All that new functionality means that there is a lot of testing to do, adjustments to make and new bugs to fix. Just as we did at the end of the SmartSDR v1.3 cycle, we are going to take more time to incorporate feedback we are receiving from our alpha team. We expect this process to take around a month."
...... though on a personal note I might be selling up and quitting HF but thats another story.... 6500 anyone...