Updated more frequent to fix important bug.

I do not understand why you do not make more frequent updates say "minor" with fixed that relate to consequent problems.
I take the example of the bug on the search limited to ten results, it is not the case, but if I had a production site, once the bug discovered, I would say what to my members. Ok I know, just wait a month or two?
No it is not possible, this kind of thing should be fixed quickly.
In addition you would be less under pressure for news, and you would have more time so less pressure and therefore fewer bugs.
You could work with intermediate updates such as 9.0.6, 9.0.7 and thus bring solutions faster.
What do you think Andrew Boon ?

  • 415
  • More
Replies (7)
    • Very true, it will definitely help

      • Comment by unknown is hidden.
        • You are absolutely right, Baloo - more frequent updates would be great. I'll give some more perspective on it:

          - One approach is to make "major-feature-updates" (X), "minor-feature-updates"(Y) and "feature updates"(Z) - X.Y.Z. This is the way you see Operating Systems or large software suites released. That's what we did with Dolphin and to some extent with UNA. The downside is that you need to create separate branches for service and feature updates, and then merge-in all service updates into the feature-update branch before release. That adds a couple of days to each packaging procedure and also complicates development, issue tracking and time estimations. 

          - Another approach is to release frequent regular combo-updates (features+fixes) and, only when necessary, urgent security patches (which get merged into the main development branch straight away). This approach is becoming more common (made popular by Chrome team) as it allows for faster evolution and reduces organisational overhead. As a result, you get versions like 9-10-11-....-67.. very quickly.   

          With current resources, we are in favour of the combo-updates route. Ideally, we'd like to release at least once a month, with both fixes and feature-updates, and also decouple it from apps-updates wherever possible (apps updates can be pushed separately, as long as they're not dependent on associated core platform updates). That's the plan, but not everything goes according to the plan...

          This upcoming update (RC10) is unusually big - it follows two rushed feature updates and includes a lot of fixes, it also required significant code overhaul for Mission: Notifications and also a few core updates to accommodate #Labels and #Channels. Moreover, we're going through all pages to clean up UX inconsistencies and run tests on multiple platforms and browsers via BrowserStack. 

          All in all - very testing times for us, as we're facing the storm of development backlog, clients requests (which is crucial for the bottom line) and the urgent need to improve deployment (Cloud) orchestration, failover, etc. 

          Sometimes I think we'd be in much better position if we did go for external funding and on-boarded more staff, but that would also mean less freedom of choice and more pressure to focus on revenue. As product-people, we rather hope to be able to build an amazing platform and let that solve everything. Keeping fingers crossed and commits coming in. :)

          • I personally think that weekly security updates need to be in place while feature/requests can be done monthly. Keeping the development demand down will help not accrue added programming costs as well as the need for hiring more people. (although I wish I was smart enough to be on the team). I think that this is sufficient in terms of updates and should be suitable for all current members.

            • Weekly is unlikely. Any update, even minor, has to go through testing and packaging; then we need to produce an "update pack" along with the new version. Another thing - people with customised sites sometimes have automatic updates turned off, meaning that they may need to push manual updates or even sometimes do code-merging. Some of our own larger clients require manual update merging to staging instances, then review, approval and re-emerging to production sites. So, even a small update takes at least one week of various procedures, besides the development itself. So, unless an urgent update is required, it is best to keep to a once-a-month pace.

              That said, I think that once we have more resources, we should be able to push more frequent separate updates to the UNA apps - those are less disruptive and once the core platform becomes more stable they should make up the build of the new code. 

              • Take notice I said weekly security updates...meaning if a possible attack becomes known or a bug in the code provides a backdoor to hackers, needs to be available within a week. Feature and requests monthly.

                • Yes, that's for sure. We usually try to issue a security update ASAP - 2-3 days. 

                  Login or Join to comment.