Stable Build

[skaye]

Is there a date planned for the near future where we will see a STABLE build of SupportSuite? The last stable build is 3.04.10 from October 11th which seems like quite a long time ago.

[skaye]

Any chance at all of getting some official indication of when we can expect the next STABLE release? Might I even suggest that you put a halt to new features and focus on delivering a STABLE build of the product so that people can implement supported versions of the product with things like Modernbill LoginShare, etc.

[Mahesh Slaria]

Hi,

We are planning to release our stable build in 10 -15 days, we are just waiting for final round of testing from QA team.

Thanks.

Regards,

[mm1250]

Originally Posted by Mahesh Slaria

Hi,

We are planning to release our stable build in 10 -15 days, we are just waiting for final round of testing from QA team.

Thanks.

Regards,

This is good news. Is the modernbill loginshare going to be in the next build???

[skaye]

So we've seen an UNSTABLE build of 3.10.00 on January 10th, is there any chance we might see a STABLE 3.10 version in the next week or so as per the comments earlier from Mahesh?

[Giray]

Originally Posted by Mahesh Slaria

We are planning to release our stable build in 10 -15 days

Call me crazy, but I'm counting. If the release happens in March, I'll be somewhat frustrated, I admit.

[mm1250]

Well, 12 days have past. 3 Days left before the new version. I highly doubt it they can live up to their word

[Varun Shoor]

Hi,
Please be patient whilst we work to iron out all remaining bugs on our TODO list.

This will be one of the biggest builds so far with quite a huge list of critical changes under the hood (New AJAX Chat Framework, Network core redesigned for Winapps).

We will be upgrading our own helpdesk tommorrow to the CVS and giving it a thorough test for a week or two before declaring it as Stable.

Regards,

Varun Shoor

[skaye]

Varun, as a new customer I can say that we bought the product having read thoroughly the feedback on these forums and as with most things alot of it was negative. We still liked what we saw from the product and decided to go with it.

The one issue I see is the time between "STABLE" builds which are effectively supportable and the functionality/feature set changes you're making. I don't mean to tell you how to run your development company, please don't take it that way, but you released the last "STABLE" build back in October - that's a long time ago. When you consider that you do bug fixes and add features in the interim I can see why it takes as long as it does, but I would imagine if I were a longer term customer that I would find the approach you take somewhat frustrating.

I would suggest that perhaps one way of delivering a better service to your customers would be to adhere to your own versioning scheme a bit more rigidly. Full version releases are rare events that make significant changes to the product and introduce major new technologies. A full version release would start with 3.00.00. That release should be support with service releases to provide bug fixes, but no new functionality. So you end up with, 3.00.01, 3.00.02, etc...

In the background you could be working on some new functionality that works off the current version framework and you'd bundle those into a point release, so 3.01.00. This version would add requested features, new ideas, features that didn't make the last point release, plus all of the bug fixes rolled up. Again, as you deliver bug fixes you'd do service releases, 3.01.01, 3.01.02, etc...

The focus would be on delivering more regular "STABLE" builds to your customers while addressing "hot fix" issues in a more simple fashion. I just see the current model as making it very difficult to release "STABLE" platforms regularly enough. You fix a bug and add a feature the same day. That feature then is reasonably untested and is added to the main line of the source.

I live by the rule that the current release branch of the source never has new features and any work on the release branch is to provide stability, security and performance fixes. New branches under development are where features are added.

So, yes we can be patient, but as a newcomer its easy to see where the frustration comes from.

[Giray]

Wise words Skaye.

[leyton01]

agree with that skaye - well said

Looking forward to this new release though - hoping it has plenty of bug fixes.

[Thijs]

Hi All,

I'm quite new here, so I won't say too much.

What I think is strange that when you buy the product, you are buying a quite old stable release.

When every reported bug is fixed in the daily build I think it can be given the status stable and than you should have an up-to-date program.

Because I'm seeing some issues on the latest Stable I need to find out if the dailybuild is quite OK.

At this moment it's all very confusing to me. What am I buying and how stable is it for the timebeing when I get free upgrades ?

Cheers,

Thijs

[skaye]

Thijs, this was confusing for me as well at first. What you buy is access to the software and updates. You then really have to choose which version you use yourself. The STABLE versions are the ones that have been tested and have passed some form of QA. Then there are the daily CVS builds which are just built upon one another and contain the most recent version of the checked in working code, but it hasn't passed any form of strenuous testing. More confusing is the UNSTABLE build which it would appear is based on a point in time CVS build and has undergone some rudimentary testing, but not the complete test stack that the STABLE builds must complete.

In terms of how stable are the daily CVS builds, well, that's hard to say really. You could be looking at today's CVS which really has been built up since mid-October without having passed the complete test stack. To some people that's low risk because the assumption is that the developer is doing unit testing on his work before checking it in, so that should prove to be relatively stable. On the other hand, you could say that until the development company signs off something as having been rigourously tested it is high risk which means you'd probably opt never to use CVS and UNSTABLE builds. You need to understand your risk profile and your tolerance for routinely updating the application.

[Varun Shoor]

Originally Posted by skaye

Varun, as a new customer I can say that we bought the product having read thoroughly the feedback on these forums and as with most things alot of it was negative. We still liked what we saw from the product and decided to go with it.

The one issue I see is the time between "STABLE" builds which are effectively supportable and the functionality/feature set changes you're making. I don't mean to tell you how to run your development company, please don't take it that way, but you released the last "STABLE" build back in October - that's a long time ago. When you consider that you do bug fixes and add features in the interim I can see why it takes as long as it does, but I would imagine if I were a longer term customer that I would find the approach you take somewhat frustrating.

I would suggest that perhaps one way of delivering a better service to your customers would be to adhere to your own versioning scheme a bit more rigidly. Full version releases are rare events that make significant changes to the product and introduce major new technologies. A full version release would start with 3.00.00. That release should be support with service releases to provide bug fixes, but no new functionality. So you end up with, 3.00.01, 3.00.02, etc...

In the background you could be working on some new functionality that works off the current version framework and you'd bundle those into a point release, so 3.01.00. This version would add requested features, new ideas, features that didn't make the last point release, plus all of the bug fixes rolled up. Again, as you deliver bug fixes you'd do service releases, 3.01.01, 3.01.02, etc...

The focus would be on delivering more regular "STABLE" builds to your customers while addressing "hot fix" issues in a more simple fashion. I just see the current model as making it very difficult to release "STABLE" platforms regularly enough. You fix a bug and add a feature the same day. That feature then is reasonably untested and is added to the main line of the source.

I live by the rule that the current release branch of the source never has new features and any work on the release branch is to provide stability, security and performance fixes. New branches under development are where features are added.

So, yes we can be patient, but as a newcomer its easy to see where the frustration comes from.

Hi,
This is exactly how it used to be until we started receiving complaints from users who said they needed to upgrade often because we released a stable every month.

Regardless, when this build goes out we will be switching to releasing a stable every month and hope that our clients dont complain on this again

Regards,

Varun Shoor

[Giray]

Though I am one of the 'complainers' I admit that what Varun says is valid. Sometimes having a stable release once a month becomes an upgrade hassle/nightmare. Then again, as long as they are not mandatory and that each build really is stable unto itself, it becomes a choice. Hmm. In all cases, I for one, am looking forward to this next release. Soon...