more G-Labs products

Author Topic: Create two distribution branches  (Read 738 times)

July 14, 2016, 01:26:19 AM
Read 738 times

amselem

  • **
  • Information
  • Jr. Member
  • Posts: 25
Hello

Since I'm using HG I've found some buggy releases and some stables ones. Sometimes the bugs are acceptable and sometimes are not, at least for a home automation system which I'd like to be fully functional all day.

I perfectly understand that sometimes there are breaking changes and bugs are introduced... In this same forum we're suggested to stick with a version that works for us and don't update. The thing with this suggestion is that sometimes I'd like to have the new features but I don't know when it is safe to update because new releases are always pushed to users as soon as are available... So I have to backup, update, try to test everything and cross fingers so there isn't anything broken.

I think this can be improved if there were two distribution branches: the stable and the beta one. The updates should always be pushed to the beta branch (just like now) and, periodically to the stable branch. Maybe there should be a poll in this same forum to vote for the most stable build from beta branch and push that build to the stable branch.
The HG autoupdater should have an option to select between the stable or beta branches (Stable by default).
This way the updates should be safer for a user from the stable branch

July 14, 2016, 05:01:25 PM
Reply #1

bkenobi

  • *****
  • Information
  • Global Moderator
  • Posts: 1525
That's sort of how it's currently set up.  Gene makes changes to the TESTING version and releases it for beta testing.  When it's been up and no issues have been reported (or issues have been fixed), he releases it to the stable branch.  Sometimes Gene sends updates directly to the stable branch presumably because nothing significant changed and he is confident there won't be issues.  If a problem occurs with the stable release, it's most likely related to a feature that wasn't actually tested in the beta branch due to available users for testing (the beta users didn't have the right hardware, etc to test the changes fully).  Either that or the update has a bug that doesn't show up for some time or is harder to track down (e.g., slow memory leak).

It sounds like you are proposing some way of rating the released version for stability after the fact.  That sounds like a good idea, but I'm not sure how that would be implemented.  I don't know if people with a stable version would come here to rate an older version.

Perhaps this could be a feature added into HG where after some number of days/weeks HG pops up a dialog to rate the current version.  I don't like popups, so I'd recommend that if something like that were implemented, it should have a way to disable it in settings.  Perhaps at that same location there should be a way to rate it instantly as well.

July 15, 2016, 02:00:28 AM
Reply #2

amselem

  • **
  • Information
  • Jr. Member
  • Posts: 25
I know that Gene has a testing version before releasing to the stable branch and I'm sure he and the beta testers do its best. It's just that sometimes the stable version... isn't stable enough.
I recall a recent build where we couldn't restore backups, another one where creating a new program reused an existing PID (and overrided existing programs!), recenly there was some breaking changes in the scheduler and so on....

All these build with bugs were released to the stable branch and publicly available to download during days if not weeks before the fix arrived. Now imagine someone evaluating HG for the first time and finding these problems, he probably would discard it as its daily driver!

What I'm proposing here is that we should have some sort of staged distribution of the builds. Each build that Gene releases to the stable branch would be distributed only to the users which have opted-in. After some criteria is reached the build is distributed to all users... that criteria could be time based (example: if there isn't any newer builds during 2 weeks, the latest build is globally available). Another criteria could be feedback based, so if I find severe bugs in the current build I could downvote it so it isn't globally distributed. The lack of negative feedback would signal a good build candidate to be globally released.

The goal here is that the stable build is always a (mostly) bug-free one.

July 15, 2016, 05:03:49 PM
Reply #3

bkenobi

  • *****
  • Information
  • Global Moderator
  • Posts: 1525