True. 100% agree.
2 Likes
The heck w/waiting!!
I have replicated the 2.2.4 beta in a COBOL code set. I will make it available for download soon. I believe you can find 1990's vintage IBM and Unisys mainframes on eBay reasonably priced. Or maybe an AS400? 
1 Like
Actually, an equal problem is feature creep that keeps delaying release as the added features are tested and bugs are found and addressed that were caused by code changes for the added features. It’s not enjoyable for those of us struggling with one issue or another.
Over the past week I have seen instances where new things were proposed by members of this forum and then promised by a Hubitat staff member. At some point, the feature set needs to be frozen and new features scheduled for the next release, not the current one.
Just my opinion based on my experience.
2 Likes
Feature creep is insidious, of course. However, if you imagine a team of 4, if persons A and C are working on bugs and thus delay the release, can persons B and D go through their ToDo list and add some of the simplest features? Seems like it's a balance. Perhaps they've even coded the feature expecting it to go into 2.2.5 and found there's a slice of time to bring it forward because of the larger bug fix work.
In other words, if I were on a team such as that I'd ask the others if they expect another Beta release. If the answer is universally no, then I'd push my features that I just coded and tested to the next release. If the answer is yes, then I'd ask if my feature, coded and tested, can be added to the next Beta.
That seems like a more incremental approach vs a more strict, Feature Freeze approach. IMHO 
Yup...in my experience working w/dev teams, anything that went into beta was automatically feature-frozen, only bug fixes or removal of problemmatic features were permitted, and the latter only when the feature was deemed isolated enough that it was safe to be removed, and too risky to try to fix. The latter happened rarely, as we had a robust Alpha process.
Any new requests during a beta went into the planning list for the next release. This was in an Agile development environment.
But I get it...the HE team is motivated and wants to help their users.
1 Like
Off topic, but I will say that "agile development" is the worst thing to ever happen to software quality.
Why? Because there is always another release coming soon to fix all the ■■■■ we didn't get right in this one. So you are in a perpetual state of fix the bugs in the crap that made it out the door in the last release.
I miss pre-internet days. Software came slower, but it came with much fewer bugs - because it had to, you couldn't just install patches all day long like you can now.
"Agile Development" is right up there with "Just in Time Manufacturing".... Which is only "Just in Time" for the manufacturer, not the customer. It is a negative 100% of the time for the customer, as all of the cost saving JIT Manufacturing touts aren't passed to the customer anyway.
I'll get off my soapbox now.
7 Likes
Luckily not my experience w/our teams...we had improved releases, with better managed feature sets as folks didn't have this "Sh_t, if I don't get it into the March release I have to wait until the Fall release!! We must deliver something in March!!!
Both Agile and the traditional Waterfall dev processes can be used for good or evil, in our case the Agile process fixed some bad habits and didn't generate a bunch of new bad habits.
3 Likes
Far enough. My problems with most "agile" teams isn't the process, it is typically poor leadership and forced release dates coupled with lack of ability to execute in the required timeframe - and not wanting to push feature x to the next drop.
And a lot of that can happen in any environment. However, "agile" makes it a lot easier to rationalize (and in practice makes it happen more often).
But whatever. Coders will code, and all.
3 Likes
And marketing and sales will over promise.
6 Likes
Allowing scope creep is a recipe to a never ending beta period.
I was surprised when Bruce said he could add RM import/export after they said it was in beta & i asked how was that possible - if it's in beta there is a code freeze, right?
I get it - i'm not complaining. Smaller companies can run on a more 'agile' framework than larger companies due to the communications being easier. Still i personally feel that its a lack of discipline.
2 Likes
IMHO the greatest evil known to man... 
3 Likes
How about RPG II on a System/3 ???? Been there, done that.....
Poor leaders will lead poorly. 
Nah, they just lead REALLY WELL in the wrong direction.
Take that Dilbert! lol
3 Likes
2.2.4 will be out before 2.2.5
4 Likes
So you're assuming that 2.2.4 will make it out the door before the testing/correction iterations drive it to 2.2.5.... 
1 Like
As I have hypothesized before:
Well they only have 999 times to get it right before they have to increment to 2.2.5. With the way it appears to be going (no inside knowledge here), they will be in the 2.2.500 series before we know it.
2 Likes
I personally think that we should all realize two key points in thinking about "when is 2.2.4 coming out":
- there is no question that the degree of complexity (and regression testing) for Hubitat has increased dramatically over time due to the incredible flexibility and control that Hubitat now offers
- in my humble opinion, 2.2.4 is perhaps one of the largest, most significant, releases yet (think of Hub Mesh significantly)
"No Hubitat Release before it's time..."
3 Likes
I agree. I think there is almost TOO MUCH new stuff in 2.2.4... LOL
Biggest single release I can think of.
4 Likes
