I recommend upgrading with the build on the website now it fixes this problem as well as many others. If you look and it’s the same build ignore it they made changes even though they didn’t update the build number or the release notes I’m guessing due to getting it out timely after hours. I can confirm this update was available on website approx 7pm Friday evening. It fixed several of our issues including this one. There are still other problems still being worked on like the search results delayed operations I listed in another thread.

Please, for the love of everything you hold dear, do also mention the SM version you are talking about. Are you talking about an update for SM 15.x, 16.x or 17.x?

SmarterMail Enterprise
Build 6915 (Dec 7, 2018)

6915 can refer to different major releases, v15m, v16 AND v17. Kindly specify the full version when reporting. Thanks!!!

Referring to @Paul Blank...
The format they specified is our new format for "17" now just SmarterMail. Seeing "Build X" means it's the new release format, and will be how people can safely refer to SmarterMail. No need to specify 15, 16, 17. As the concept of major versions becomes less apparent the need for this will disappear.

I understand your decision, but this is a bad idea, just saying. Think about it - you`ll probably have 6915 in v17.1.x too (and so on). 

There were enough problems already - more confusion with the versioning is sure not something everyone needed on top of those.

The build number is constantly increasing, as it is the number of days since Jan 1, 2000. "17.1" and such won't re-use this number ever. The only time I think we can have confusion over this build number is if we have same-day releases, which we don't do unless there is an emergency fix that needs to be put into a build.

OK, so to understand it, you`re going down the Microsoft route ("Windows 10 is the last Windows") and you will never, ever want to restart / reset SmarterMail in the future? Let`s say some new technology comes out and you will want to rewrite SmarterMail from scratch 5 years from now, you will simply increment the build number?

Anyway, this question is not critical; sorry to hijack the thread..

Yes, you are correct in that SmarterMail is the product and the build number just gets incremented, similar to what Windows 10 does.

Unless the new technology makes us move away from a web browser, then there's no reason why we would need to change the "version".  Simply increasing the build would suffice since the technology behind our app should be irrelevant to the end user.  Obviously our release notes would list all the major changes so we could disclose everything to hosting providers and email server admins.

Thanks.

We don't want to take as big of steps. 17 was a massive step, we just did so much on the backend, how we deal with data, config files and what not. So for now we wanna take smaller steps in increments, maybe bigger "monthly" or "bi-monthly" feature upgrades. However since doing all this we have a lot to continue, MAPI and then tightening all the loose bolts. We will instead try taking a more gradual approach to releases. We wanna take a more slow and steady approach to our features and releases, instead of busting out a major every year or couple months. This allows us to focus maybe on one major feature at a time while balancing bugs and tickets. 

OK, let`s see how this goes. I still think that all of it could have been done and still use normal software versioning conventions - at least things would have been clearer (I do not see what`s the problem for example in having a release, like let`s say v18 that spans over many years, with versions like 18.1.x, 18.6.x, 18.15.x and so on if you just want to focus on taking it slow and not releasing a whole new product again). I also understand what Microsoft did, but just because they did it, does not mean it`s good. There are so many issues with Microsoft`s rolling release model that it`s a nightmare. Of course we still need to use it and adapted to it. But I do hope that they do not set a trend that will be picked up by all software companies to follow..

The thing is that these build numbers are not meant for the end users - they do not care. These are meant for the administrators, many of whom also have experience with some form of software development. If you choose to keep things clearer, you do it for the administrators, if you choose to blend and confuse, you do it for the administrators again. 

Now, since SmarterMail is the product and there are no versions, just builds, in case at some point you reach a roadblock and mess up so bad that no one will want to use that version (think Microsoft with Vista), you`ll have to switch to a whole new product (e.g. SmarteRerMail), instead of saying that now you`ve completely re-written v19 from ground up and it`s different product than v18.

Another example: I`ve been promising MAPI and "MS Exchange Server-like functionality" for some months now to my higher-ups, which was to come in SmarterMail v17. Until now it was easy to say: hey, we`re on v16 and v17 is in BETA, and as soon as that comes out, we`ll upgrade and have MAPI, the green pastures, et. al. Then MAPI was pushed back to v17.1 - again it was relatively easy to explain to higher-ups: SM 17 will be released soon, but MAPI did not make it in the initial release, but it`s coming in a point (e.g. 17.1) release - we could all understand it, even accountants. Now the goalpost is ever moving, just like a mirage: MAPI is coming in a new SmarterMail build - stay tuned. 

Again, I understand it, but you can see it confused some users (as was the case with me with the problem reported in this thread), whereas no one was ever confused when someone reported a problem against SM v16.3.6897 for example.

Hello Ionel, point taken.  I can see this argument from an admins perspective.  My last point on this, we didn't just change this to follow a model like Microsoft but instead because it aligns with how we're supporting the product going forth.

Also, "(e.g. SmarteRerMail)" this made me smile.