Calling All Zimbra Collaboration 8.5 Beta Testers

The Zimbra Collaboration 8.5 Beta is winding down, and I want to thank everyone who participated and provided feedback. We appreciate your support – it is your input that helps us develop and deliver better software. As an example of this, we received great feedback in the following areas:

  • Exchange Web Services configuration for Outlook for MAC clients
  • A bug found with Android 4.4 devices that prevents mail sync
  • Installation issues on Ubuntu 14.04
  • A bug that causes the mobile touch client to hang in calendar
  • A bug in HTML5 offline mode that prevents log-ins
  • A bug found with MTA configuration in the Admin Console

You can read detailed feedback in our beta forum. If you have not yet downloaded and installed the beta, the latest and final beta release, Beta 3, is now available.

For those who have tried the Zimbra Collaboration 8.5 Beta, we would love to get your overall impressions of the beta release experience. We’ve prepared a brief survey where you can provide additional feedback to help us continue to make improvements.

Thanks again to all who participated in the beta program. Zimbra Collaboration 8.5 will be released later this summer, so please continue to read our blog, newsletter and forums for product announcements.

,

8 Responses to Calling All Zimbra Collaboration 8.5 Beta Testers

  1. Nochum Sossonko July 10, 2014 at 10:15 AM #

    What happened with Always On? I didn’t see any of that in the previous beta. Has that been scrapped for 8.5?

    Thanks.

  2. Jorge de la Cruz July 11, 2014 at 3:16 AM #

    Hi Nochum,
    I saw a few things for the Always-On in this Beta:
    Move to MariaDB
    Also in installation, you can install Mailbox Role and MTA role with o without web server mode, so this is the first step, for build a distributed architecture with mailbox role only with MariaDB running and syncing data, and other mailbox role serving only the webmail.

    :)

    Kind regards

  3. Nochum Sossonko July 11, 2014 at 8:48 AM #

    My point was that there was nothing on multi-master (or failover) mailbox nodes in this beta, as far as I could see. Earlier last year there was a post about storage becoming multi-master (or at least failover) capable, I am wondering if that is still futuristic?

    • Jon Dybik July 14, 2014 at 3:16 PM #

      Always On is being delivered in two phases. Phase 1 in ZCS 8.5 includes the switch to MariaDB, splitting the web client from the mailbox server nodes, and a lot of internal work to prepare for the distributed architecture coming in Phase 2.

  4. kostas pappas July 14, 2014 at 4:25 PM #

    Well done to all the (telligent) team for the hard work.
    we support zimbra and open source
    one note from me, please do it something with licences, we need better price to compared with office 356
    thanks

  5. sanalium.com July 15, 2014 at 9:57 PM #

    My point was that there was nothing on multi-master (or failover) mailbox nodes in this beta, as far as I could see. Earlier last year there was a post about storage becoming multi-master (or at least failover) capable, I am wondering if that is still futuristic?

  6. Enrico Weigelt, metux IT service July 28, 2014 at 5:27 PM #

    Build system is still pretty broken.

    The worst part is the messy 3rdparty bundling. You _really_ should use the OS provided packages.

    And looking at the SCM history is pure horror. Ever came to the idea that it might be a good idea putting one semantic change into one consistent commit instead of committing it 5 pieces ?
    These complex merges also dont actually make following/reviewing history easier … ever heared about rebase ?

    Even though the situation improved some bit since ironmaiden,
    it’s still pretty bad – I’d consider that codebase alpha stage.

  7. bofh October 7, 2014 at 7:15 PM #

    @enrico weigelt
    the third party bundly may seem messy but totally make sense.
    specially when you look at the different culture within the distributions.

    you cannot allow someone to upgrade a package by its distribution and may break zimbra for good. zimbra would have to shoot out patches to cover those breaks by updates for every distribution.

    further an update doesnt mean nessesarly its a good thing (iam looking at you ubuntu) so while still relying on opensource technologies NOT relying on a distribution in that very delicate and complex bundle is the only way togo.

    the other option is just messier than this.

    however i whish for a better and clear difference in the directory structure, i know i may sound cosmetic but pulling packages/symlinks/data and config into one directory is a bit messy
    and harder to cleanup

    btw: zimbra is one of only a few if not the only one who was able to provide a stable and most of the time hasslefree upgrade path over year and years, even across multiple major releases.
    so drastic changes within internal developing workflows seriously put this at risk

    saying that this is codebase alpha is a joke at best.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures