Big or Small releases thats the question

kludon

As Emile said the Homey team had discussed about Major or minor releases. They came to the conclusion that Major releases would be better then minor ones. I'm working at a software company where we also had this discussion. Maybe you can Look at DevOps. This is how the bigger software houses works like Facebook and Microsoft. The idea is developing Small pieces and bring them automated andto fast to the Production State. Smaller pieces means less bugs (smaller code changes) and easely to find if there is a bug (less code to investigate). When there is a bug, it will be fixed the next release (within a week). I Hope that I gave you some extra information for this discussion. Just my 2cts

Phuturist

I'm an Agile coach and currently occupied with coaching DevOps teams. One of the concepts these teams are adopting is continuous delivery. I got a bunch of reasons why smaller releases are better but this is something the Athom team has to find out for themselfs. Bringing in some knowledge on Agile and continuous delivery wouldn't hurt though. It could help the team to organise their work and workflow.

If the Athom team thinks they need bigger releases for bigger projects then they aint slicing the (new) features into deliverable user stories right or they are not trying to improve and automate their delivery process enough.

For anyone interested in this first subject, a good read is 50 ways to improve your user stories.

But I'll stop now ...  

RamonBaas

The Phoenix Project is also a nice read in that respect.

caseda

If athom was a big company, or if homey is only reliant on 1 software part (which it isn't because it works with apps) i would agree.

I think you could better compare homey with Android or IOS that only gets a big update once a year, why?
because it doesn't need it more often in the core (except for very crucial updates).
The same goes for some Linux distributions, they don't get updates to the core that often.

If there is something that needs many updates, it will be the apps that are written.
And if i see it right, every app well get accepted within a week when updating (created by community apps that is).
so to see it more theoretically, homey gets updates every day.
Just not in the core department, you'ed want the core to be stable as it can be.
Which i must say, it is pretty stable right now.

my 2 cents.

bvdbos

Of course you are correct, thought about that too. However, deploying IR, Music, Bluetooth etc etc all at once can cause so much problems Athom loses control. They've been there already...

RobinVanKekem

Lesser updates but of higher quality is my suggestion

DaneeDeKruyff

One thing that's missing here is quick-fix releases.
Bugs will be introduced on new versions, regression will happen. For example; While 0.8.38 was fairly stable 0.8.39 was released as experimental, but contained a confirmed bug that broke z-wave and deemed won't fix. Yet it was promoted to stable! We had to wait (can't remember how log, but way to long) for 0.9.x for z-wave to be available again. That should not happen again.

bvdbos

In the past we had a 'release fast release often' update cycle, which was very good for us during that period where many bugs were found in short time. Now that Homey is getting more stable, it makes more sense for us to move to a cycle where we release an update every few weeks. This enables us to take on larger projects, test more thoroughly and generally be less stressed about releasing.

I don't understand this. Homey is stable but not mature, a lot of parts are still missing. Why roll new features and major updates out all at once with the risk of getting  total defunct product? Or would Athom have to rewrite the entire core once again to support BT? Or to support Music (BTW: What's music: Spotify? DLNA?). What if Music has an issue which influences BT? Then it requires bugfixing two parts... Of course a fix for Music might break BT or Zwave but then you know where to look. If everything is released at once it's going to be hard to pinpoint the cause of the problems and to roll-out new fixes. There's five different things imho:
* User-apps : these are updated on daily basis (well, mostly approved within a couple of days)
* Athom-apps (not on Github) : these are updated on irregular basis (as far as we know)
* Existing Homey Core : bugfixes should come out as soon as they are discovered (and fixed) in experimental
* New Homey Core features : these should be delivered one by one  to keep control on the process
* OS: We've seen the update-process failing with OS-updates before (image can't be extracted etc) so these should not be delivered at the same moment new Homey-Core or apps come out (I know, this cannot be avoided all the time).

JaapPelt

The announcement confirm things are moving in the right direction. It gives me a lot of confidence. Athom is growing up as expected and these steps confirm it.

Every company and every product has it's struggles. When I backed the Kickstarter, I did not expect a finished product to be delivered at launch. What I got instead was much more. I really enjoyed following the development of Homey and Athom. Being part of the process has been fun. I'm looking forward to the 1.0 release.