+1 

Agree on this all

/rant mode on

I'm now tired of being a beta tester for a product that I PAY FOR and which should already be stable...

In fact, for a few days (weeks?) I've been stopping making updates, now I'm just waiting to see in the forum if a version is stable enough, otherwise I'll stick with the old one until no one complains anymore...

Also because I'm a little disappointed by the fact that some of my posts are suddenly deleted without any warning or contact from SmarterTools...

So: thanks for the product (I like SmarterMail and in my opinion it will become the best, I hope...), but my job is NOT to be a BETA TESTER... Especially by paying to do it...

Sorry for the outburst, but I think I contributed a lot in the last three years (for free or, worse, paying!!!), and now I'm tired of doing it endlessly...

/rant mode off

+1

Also echo that I'm very happy with the development of SmarterMail and pleased with it's features. But it would be very nice to have a LTS channel that is super stable. We've been bitten twice on new releases in the past year. Thankful for the great support team to help resolve issue, but we value stability over cutting edge.

+1 on LTS.  Frequent updates with new features is reasonable for those doing general hosting and who like to stay on the bleeding edge, but in corporate environments stability is king.

Vendors that are serious about inroads with larger corporate accounts should always offer an LTS branch, with a slow, steady release cycle.  Some of the LTS software we use makes releases no more frequently than Quarterly or Semi-Annual.  New features added to LTS have to be qualified in their general release branch for a period of time, before being merged into LTS.  When LTS adds new features, we install with confidence knowing they've already been proven stable.
 

+1 for not going the Microsoft route (the land where every install is a guinea pig) 

+1

We upgraded to the latest 8797, and apparently there are "issues" with various things.  Then an update comes out and i am reading through all of the posts about the next release, and it seems like we would just be trading known bugs for new bugs, fix the old and get new ones. 

All of that is one of the reasons why we stayed on version 14 for about 7 years. We knew what we were dealing with.  

Agree completely, stability over fancy, every day.

I prefer to have a Stable channel and an Insider/Beta. 

Nobody wants to go back to .NET 4 is super old technology and slow.

ATM the latest build of SmarterMail is quite stable.

As an application developer for over 30 years... 

1) There is NO SUCH THING as bug free code (not just with SmarterMail, not just with Microsoft products, but ALL software that is anything more than a basic "Hello, World" application)

2) Any code that consists of more than a dozen modules is going to have interactive situations on updates where something new may impact the functionality of something old.  Should it be tested and sorted out... absolutely.   But... refer to rule 1.

3) When you are a Microsoft .NET based product (and SmarterMail is) the underlying architecture is constantly changing.  If you are using anything beyond the most basics of the .NET environment... functionality is going to change on you when the enviroment changes, not just your code.  As such, you must be constantly evolving to make things continue to work as expected.

4) OS updates impact the installed programs on a machine.  Highly specific coded modules packed into application specific DLLs remain unchanged, but when the underlying OS DLLs are altered (and are used by the application)... their functionality changes in the application as well.  This can result from deprecated operations, altered implementations, altered requirements and/or altered functionality.  The developers have NO CONTROL over this and REACT accordingly to fix their code in a software patch.  SHOULD they be aware of upcoming changes?  Absolutely.  Does Microsoft tell you every single DLL that will be altered in the upcoming service patch and what those changes are?  Absolutely NOT.

Not making excuses for SmarterMail... just speaking generally.  Your LTS solution is going to contain bugs as well... 'tis the nature of the beast.  And, the LTS will be susceptible to the same environment changes thereby requiring patches to the LTS as well moving forward.

Beta testing anything requires an active environment willing to take the risk of experiencing issues. The problem is the active environment. Who of us has a domain they can run on beta software that is regularly used a lot? And I don't just mean to send and receive test messages. Beta testing means getting ugly with it, trying to do things your clients will do that make no sense but work. 

What is needed is a way to re-process the archive from a specific date. Right now I perform an upgrade in the middle of the night after having made an image of the server as well as a backup of the data. Given the restrictions on successfully rolling back from some upgrades I try and validate as fast as possible the server is working, if not I load back the server image and lose a couple of spam messages that were received while the new server was up (and any valid emails). That doesn't allow for what happens when someone finds a problem two days later and thousands of messages in & out. If I have to reload from the image I will lose all those messages. If I try and recover from the data backup then I have to deal with any conversion issues that were going to make a roll-back fail. If we could re-process the archive from a specific date and time then we wouldn't be so scared of loosing email after an upgrade. 

+1 for mark

@Rod Strumbel - We understand the underlying environment changes, and software has to adapt.  The spirit of this thread, however, is not to suggest the LTS branch must never change.  Not the case at all.  Take Windows Server products as an example.  You can install the LTSC branch, or the more active track.  LTSC receives timely fixes (a/k/a "quality" updates) but new FEATURES are added on a much slower cadence.  This produces a more stable compute environment-- one that is regularly patched for security and functionality, but does not introduce new problems via a constant additions and new features.

THAT is what we're asking for from SmarterMail; a branch that receives new features less frequently, so we're not riding that constant "new features, new bugs" merry-go-round, while still having a branch that actively receives security and quality updates.

Meanwhile, those who like to always want the newest features can install the "active" branch and spend the time fixing bugs and stabilizing them, before those features are rolled in to the LTS branch.
 

Amen!

What Jay Said. 

We dont run anything else than LTSC branch when we host clients. Uptime is everything.

+1 for an LTSC.

@Rod...

1. No one is saying LTS does not have bugs, the point is to fix and minimize bugs by not constantly rolling out new features that can cause new bugs or reintroduce bugs.

2. This is the reason for LTS, you dont want to add in "new" things (other than bug fix code of course). Patching existing code to fix an issue is much less error-prone than adding in something completely new.

3. .Net fwk is stable and is not getting new features added to it, it's bug and security fixes only. .Net fwk 4.7+ has no EOL date currently and I am sure Microsoft is going to continue to support it for the most likely very long future. Changing from one .net version to a completely new .net environment that now runs on a completely new set of operating systems is of course adding in 100s if not thousands of new variables.

4. Possible, but pretty unlikely. 99% of the bugs we've encountered with SM have been SM-related, not .net, not a 3rd party app, not some 3rd party modules.

I dont see an issue with having an LTS build, a bleeding edge "stable" build and a further looking beta build. I understand it takes more manpower, time and money to support this, but it's beneficial in the end for everyone, especially ISPs and larger enterprises that want bug fixes and stability over shiny new features.

Take for example the current new build (8965) has a fix for a bug we reported with EWS dying (with eM Client) when downloading certain messages with attachments. In order to get this fix, we have to risk installing a massive build with new features, changes and other fixes. The fixes are fine, but what issues will now come out from all the changes and new features. The risk to reward is too high.

@echo

Totally agree. In this day of age, we cant afford to tell customers to go for an inferior product in all aspects compared to Office365 and others.

If we fuck up by pissing them off installing a beta in production that doesnt deliver basis error free mailhandling, then they are gone.

So compared to Exchange, even though the cost somparison is in SM's favor, the bugs introduced in the new builds and the possible reintroduction of old bugs and the subsequent loss of a client cloudl make SM a lot more expensive than just running Exchange and be done with it.

@Brian said:  "So compared to Exchange, even though the cost somparison is in SM's favor, the bugs introduced in the new builds and the possible reintroduction of old bugs and the subsequent loss of a client cloud make SM a lot more expensive than just running Exchange and be done with it."

This is exactly what we have been facing in real life.  We've already lost some people to Exchange 365 solely because of the endless problems of Outlook/MAPI.  Additionally, we went through an incredibly tense period with a very large client (six-figures annually to us-- yeah, that large) about a year ago who was getting Exchange 365 bids from a few consultants local to them. The account was saved, but once again they are getting outside quotes all because of MAPI issues.  Everything else works fine-- webmail, POP, IMAP, ActiveSync-- but big corporate lives on Outlook.  Period.  And every time one MAPI problem gets fixed, two more take its place.  

This weekend's update to 8965 was a total disaster that blew up all over us this morning, so bad that we had to revert back to 8930 because too many MAPI users were suddenly unable to use Outlook.  That build should NEVER have been released as production-ready.
 

Usually I read the various forum threads here before upgrading. I simply broke my own protocol and performed the 8965 upgrade without thoroughly reading the posts here describing the problems people have had. Jay, have you had any other issues introduced by the downgrade? I have to do it tonight. And, your observations and Brian's are spot on. Partly, this isn't a SmarterTools problem in that the cost and ease of running Exchange services are so much less with M365 than the old days of on-premise Exchange. Competing against MSFT is just plain difficult as they gobble up the market with a generally compelling product. That said, these MAPI problems have made so many of my customers wonder why they shouldn't make the jump. Luckily, for me, there is great loyalty of my customers but their threshold of pain goes only so far and I'm hearing it loud and clear. Today, for example, I threw my hands up and told one of my long term customers, "Hey, I don't blame you for jumping ship if you make that decision based on these ongoing problems." I get revenue either way as an IT consultant but I would definitely lose as a mail service provider.

This isn't a criticism of SmarterTools as I know they work very hard to deliver a quality product. More so, it's just a statement of fact that I'm feeling more and more heat from clients as I've moved so many of them to MAPI. None of these problems exist in the IMAP/POP/EAS protocols. If it weren't for the fact that Exchange functionality is what they want, this wouldn't be so great of an issue.

Problem 1. They didn't make a Release Candicate

Problem 2. Somebody must test the Release Candidate on a production enviroment and be online 24h to revert back on a serious problem.

Personally I've tested the betas on my Personal PC which i use the Free version.

Rolled back to 8930 from 8965 a few minutes ago. Went smoothly and instantly solved the MAPI problem. Not aware of any delivery or system issues after rollback.

@Matthew Titley - Sorry, I just saw your question from yesterday about reverting.  Our admin did it yesterday morning, and the call flood stopped immediately.  We're not aware of any problems related to reverting to 8930.

 

The issues discussed in the community existed during the beta testing period, but were not discovered because not everyone was affected. A small number of users and servers experienced some bugs while many did not. We are glad to report that a large number of customers are using the current release without any issues. Today, we are releasing an update with some fixes and a few additions. Before we release, we lock our code while testing it through various channels. When we release, it is the locked code with the current date as the build number. We hope this information helps.

I like Smartermail. I like it alot. That being said, Ill be the first to admit ill usually update to 1-4 builds before their next major release (Just look for the jumbo sized patch notes) and sit on that release unless if they find a security issue which they usually notate in the notes. 

Most issues we come across don't need a feature release so much as a bit of guidance, and We can usually get that out of support even if we are running a 6 month to a year old release (We don't run builds any further out than that)