[color=#000000]SuiteCRM major releases seem to be coming with an increasing frequency, the dates for the last 4 being (taken from the git tags):
v7.1: 1st April 2014
v7.2: 2nd March 2015
v7.3: 14th August 2015
v7.4: 30th October 2015
Based on this it would seem that the approximate gap between major 7.x releases is halving between each release, having gone 11 months> 5.5 months > 2.5 months. If this pattern continues, the 7.5 will be released at the end of December, with 7.6 in mid January.
This creates a problem for organisations deploying SuiteCRM, since we have no idea when the next major release is coming and can’t plan for it in our own upgrade cycles. Furthermore, there is no obvious published policy stating how long security patch support for earlier releases will be continued, so we can’t plan for the expected “End of Life” of our current version either.
Can I suggest that you decide upon a more consistent release and bug fix schedule, which is then published so that all your users can plan ahead with certainty? The model used by the Moodle VLE is quite a good one for an open source project. Major .x releases are released every 6 months, with the expected dates of code freezes, betas and releases candidates being published well in advance. Furthermore, the expected end dates for bug fixes and security fixes is published when the release is made, as a general rule each .x release is supported for 18 months, thus allowing organisations using Moodle to operate with a single annual upgrade for major releases, safe in the knowledge that the version they are using won’t be dropped before the next annual upgrade. See:
Minor point releases with urgent bug fixes can still be put out as required, it’s the major 7.x “this might break something when you upgrade” releases which are the problem.
I don’t personally care how you formulate your policy as long as it is published and consistently applied.
Personally I welcome and appreciate the new releases.
Sales Agility are working hard at improving the product (and it has improved enormously since it was just SugarCRM!!!).
It is indeed a problem to having to upgrade but, from my point of view this is a HAPPY PROBLEM because each realease comes with new necessary or very useful features as well as bug fixes or improvements.
Additionally I am seeing that Sales Agility are also working towards simplifying the product structure (not an easy task!).
In the last version we have seen a simplification of the installation process. I see in the roadmap that the custom folder is coming in a few months. Obviously change is difficukt to accept but I can’t wait to have it to have all the benefits!
amariussi, the problem is that each 7.x release has to be tested against all of the other systems which it needs to work with, this takes time, which costs the business. Such major releases usually break things, which then need to be fixed. Increasing the frequency of 7.x releases, increases the cost of this testing work.
Also, for business reasons, I prefer to only implement major upgrades during holiday periods when things are quiet and the consequences of something failing are lower, so this limits the window of opportunity for upgrades. I have to decide prior to Christmas whether to upgrade to 7.4, or to skip it and stick with 7.3 (we skipped 7.2). If we stick with 7.3 will it still be receiving security updates next Easter when the next upgrade window occurs? The Roadmap shows that 7.5 and 7.6 will have been released by then. Will 7.3 still be receiving updates through to Easter? I have no idea, because there is no support policy. My inclination would be to not perform another upgrade till next July or August, but 7.3 will be out of support before then at this rate.
I would normally expect, in the absence of information that a major .x release would be supported for 18 months, this fits in nicely with annual deployment strategies which many companies use. If we are now going to be seeing major .x releases every 3 months, then this means that Sales Agility will be supporting 6 concurrent versions quite soon, which many companies would consider uneconomic.
Upgrades are good, but product stability is also very important if you have a lot of other dependent systems.
I also work on the Moodle VLE, which suffered from a similar problem some years ago, so I started a similar discussion. This rapidly resulted in a very clear policy being developed and Moodle has benefited enormously. SuiteCRM would do well to follow this example! I don’t want to knock Sales Agilities hard work, I’m posting this because it’s obvious that SA haven’t realised the extent to which this will hinder the large scale deployment of SuiteCRM, something I’m sure they want to see happen.
The main issue is that SugarCRM CE had been literally abandoned by SugarCRM in favour of their paid version.
It hasn’t been long since Sales Agility have launched SuiteCRM and I understand that one of their main priorities is to close the gap with all those things that SugarCRM had reserved only to paying subscribers.
I have followed very large global telco retailing, pharmaceitical, corporations and they had planned releases, but in the past years these releases have become much closer. In some cases once a month. This is due to the fact that the world has evolved enourmously and a few months are an eternity today.
If you had seen the Roadmap posted by Sales Agility until a few weeks ago, there were lots of things to be done. Some of them had been done and other not.
Since September Sales Agility has committed one date for the next version.
Today there are three dates for three future versions.
In each of these versions there is a declaration of what they are willing to achieve.
There is still something missing, but rather costly: a more detailed list of what is contained. However, I believe that, once these three releases are out, not only the gap will have been closed but SuiteCRM will become, possibly one of the best CRM around altogether. Not just in the Open Source arena. (I don’t mean it isn’t today because I believe it is already, but imagine it with those things that are in the Roadmap!)
Consider that the product is completely free. If you want more support you pay something. I believe that, the more advanced features the product has the more companies and corporations willing to pay for support so speed is crucial.
When Sales Agility tried to raise some funds, I bid for my part but, unfortunately it didn’t work. Still they are investing more. Personally I try to contribute, with all my limitations to help others in the forums, hoping someone will help me when I need help and that Sales Agility continue filling the gap.
This isn’t about slowing the pace of development, it’s about the point at which you decide to take the collection of features you have developed, at whatever speed, over a period of time and call it a new major release. I would prefer a 6 month+ cycle, but I don’t really care if they choose 6 weeks if that fits better with their development approach. Mozilla Firefox is released every 6 weeks, I think this policy is very badly wrong, but it clearly published and can be planned for. Fortunately there is an ESR (Extended support Release) version of Firefox, which I use instead.
The number one critical issue for me here is that if I deploy SuiteCRM today, how long will the version I use for that deployment be supported for if I decide not to upgrade? The point is to have an end of life policy for each major release. I note that 7.6 is being called “LTS”, which I assume is “Long Term Support”. However, since I have no idea what the current support period is, this is meaningless in context. I would personally assume this means 3 years. Can somebody say what it really means?
I want to re-iterate that what Sales Agility are doing is really great, but an “End of Life Policy” is what corporate software buyers will look for, so having one will drive the adoption of SuiteCRM, it won’t cost anything to and won’t hinder the pace of development. I am doing this to help them, because I think this is holding SuiteCRM back. More people deploying means more potential customers for SalesAgility, which means more money for faster development. That’s a good thing.
All that is needed is a page which says this for each release:
SuiteCRM 7.3
Release date: 14th August 2015
End of normal bug fix support: 14th August 2016
End of support for critical bugs: 14th February 2017
That way if I deploy SuiteCRM 7.3 today, I know that need to plan for an upgrade to a newer version by Feb 2017 at the latest. I don’t care how many releases are made in the interim, or how fast/slow the development is. The point is that I know how long I can safely continue with the version I have. Ideally those dates should follow a clearly established policy, so that I can predict with a reasonable degree of certainty what those dates are likely to be for future unreleased versions.
Most larger companies consider such a public, published policy to be a red line when choosing software, SuiteCRM needs this to play in that market.
One further thought, I’ve got no problem with paying for additional or extended support if there is a business case to do so, but until I know what the End of Life policy is for the free release, there is nothing on which to base the decision as to whether or not the extra support is worth paying for. SA could generate revenue by offering “extended” support for older releases only to paying customers.
I’m really keen to get an answer to my question. “End of Life” policies are the norm for most enterprise software and Sugar have a stated policy here:
Which could be better since it’s not clear what the target release date for 7.7.0.0 is (for I know it’s out now, I can’t tell), but it’s more information than is currently available for SuiteCRM.
I want to re-iterate, this isn’t about slowing development. It’s about enabling people who use SuiteCRM to plan ahead. The current situation is causing me some difficulties.
I am not sure if you are expecting an answer from me since I have participated in this discussion or from any SuiteCRM user or from Sales Agility.
I am going to try to explain my personal position here, but I wouldn’t like having to reply again as this discussions, may become sterile without other participants.
With respect to my own personal opinion, as I said, I understand your point of view and, although I may even agree partly on it, I still appreciate the tremendous effort made by Sales Agility into turning SuiteCRM into the best CRM system available.
There are still many things to be taken care of but the direction is the correct one.
With respect to publishing in advance version dates I believe they have started doing it but I also understand what their point of view may be (in fact I don’t know what it is, I am just supposing): it is probably very difficult to commit on a detailed list of new functionnalities or fixes since the budget is probably limited and it’s only an investement on their side.
With respect to upgrading everytime to the newest release or version I think that, depending on the problems each one is eperiencing with their current release, and the new functionnality and fixes introduced everyone is free to upgrade or leave the upgrade for a future release or version.
With respect to set recurrent dates for new releases or versions I believe that this is a policy that each company has to reserve the right if and how to adopt it. There is no law nor rule nor code of conduct on this subject. Every major software vendor as always had its own policy. And these policies often are not respected or are modified on the go.
With respect to support to certain releases or versions and their end of life, you should bare in mind that this only applies to those companies who have purchased support or that are using SuiteCRM as a service from Sales Agility. I do not know the terms of these agreements, but I beleive they must have some way to define the end of life of a version with thos customers.
For those who do not purchase support nor do they use a hosted version by Sales Agility the problem is simply solved. Once a new version comes out this should be the reference version or release. New additions or fixes apply to the next current version or release.
Personally I would like to have certain things with different priorities and also a plan of dtes and new functionnalities or fixes for me to plan. At the same time I know that this is a completely open source project and, not only do I accept it as it is, but I also appreciate it very musch as I do appreciate the tremendous effort paid (not only in terms of time but also in terms of dedication and funds) to SuiteCRM.
I was hoping to get an official statement from Sales Agility. We had a similar discussion in the Moodle Community a few years ago (See here: Moodle end of life), once the issue had been raised, Moodle HQ (in the form of Martin Dougiamas) responded in person, confirmed the current situation and published a policy a few days later.
As I said, this has nothing to do with functionality, the content of each new release doesn’t matter in this context. All that matters is the life cycle of that release.
This is true, but the point is right now I have no idea if by not upgrading from 7.3 to 7.4 I am putting myself at risk of not receiving a major security patch should there be a problem. If I know that 7.3 will stop receiving security patches on a certain date, then I can decide if the risk of running an unsupported releases is greater than the disruption of an upgrade to 7.4 at a time which doesn’t fit my business requirements. I simply want to understand the policy so that I can make such a decision. Right now this is impossible.
Agreed, I simply ask Sales Agility to tell us what this policy is, not dictate it. I have a preference as to what the policy should be, but in the end I don’t care what they do as long as it’s clear, consistent and public.
Sales Agility may decided to provide additional private updates to paying customers who have agreements. The point here is that I would like to know what the policy is for the public download. If the policy is that fixes will only be applied to the most recent branch, then that is fine. The point is that I want to know that that is the case. Right now I have no way of knowing which branches of SuiteCRM will receive patches if a major vulnerability were to be reported tomorrow. By telling us the policy for the free version, they are also telling us the “value” of the paid for service. In essence, you can tell what you are paying for.
Most open source projects which are aiming at the business market manage to have this kind of planning, it’s really not difficult and Sales Agility probably have a policy already. It’s really not difficult to do and it will provide clarity for users. A clear product life cycle will drive adoption of SuiteCRM (and boost Sales Agility revenue) since it will allow sysadmins to tick that all imports “clear product life cycle” box when justifying software choices to management. See the following for examples:
I want to be clear, this is not an attack on Sales Agility. This is a genuine attempt to highlight an issue which, if solved, will provide significant benefits to all users of SuiteCRM and which will significantly improve it’s adoption.
Is there any other way to a response from Sales Agility on this? Sorry, but this really really matters to me and most organisations manage to have some kind of published policy. So I’m going to keep asking here until I get an answer. If the answer is “We only tell paying customers”, then even that at least is an answer that makes sense, even if I don’t like it.
I take it that nobody cares about this, which is a great shame considering that it’s a vital piece of information for any enterprise level software deployment policy. Come on Sales Agility, you must have discussed this internally and have some kind of a plan, you’ll loose nothing by telling the rest of us what it is and may even gain from it.
Yes, it’s very relevant. This isn’t about “support” for the product in terms of calling Sales Agility and saying “I have a problem”, or “can I pay you to fix X”. The point here is that there is a freely available, open source download which receives periodic updates and security fixes. Everybody who uses Suite gets these updates regardless of whether they pay Sales Agility or somebody else to look after SuiteCRM. If I report a serious security problem to Sales Agility tomorrow, Sales Agility will fix that bug in the open source code, regardless of whether I am a paying customer or not, the people who are paying customers would surely complain if a known security hole wasn’t patched quickly, so it’s in SA’s interests to fix these things regardless of who reports them.
Lets assume that a bug affecting all versions of Suite from 7.1 onwards is reported tomorrow. Will Sales Agility fix the bug in 7.1, 7.2, 7.3 and 7.4 in the public github code? Or will they just fix in in 7.4? Or will the public github fix be for 7.4 only, while only paying customers get the fix for earlier versions as well. All of these responses are valid and perfectly legitimate business choices for Sales Agility. The point is that as a user of SuiteCRM, regardless of whether you are a paying customer or not, you need to know this so that you can plan your software deployment strategy.
I re-iterate, I have a personal preference as to what I think the end of life policy should be, but when it comes down to it Sales Agility are entitled to make whatever choice they consider appropriate for their business. If that policy is not what I would like, then I have to make my own choices as to how to mitigate the problems it creates. However, at least I know what those problems are and can make a decision. Right now, I’m flying blind and hoping that the guesses I’ve made about the software lifecycle are correct.
However, I think Sales Agility have now taken note of this (Thank you!), see the comments here:
I’m guessing bug fixes only go in the next version released and old versions are not touched but as you say it would be good to know if that’s the case
I’ve seen bug fixes to older releases as well, I’ve not sat down and exhaustively analysed the pattern though, but it seems like the two most recent releases is a reasonable assumption. However, we are both guessing and there is a 7.6 LTS release coming up which will have a different but unknown policy.
Right now, I’m on 7.3, upgraded last summer. I would prefer not to have to make a further major upgrade till next summer, but if the policy is “2 most recent” for public fixes then I need to schedule a major upgrade for January when 7.5 comes out. Ideally the upgrade should happen over Christmas when things are quite, but that means going to 7.4, which might be end of life in April when 7.6 turns up, requiring a third major upgrade in 12 months, something I try to avoid. Ideally there needs to be a maintenance period overlap so that people on the version which is close to end of life don’t have to upgrade on the day the new version is released. It takes time to test a new release and make sure it works with all our other software, this process can’t be started until the final release version is available (we don’t have the resources to pre-emptively test against beta releases and deal with bugs which might be fixed in the final release).
I have a strong personal preference for major point releases every six months (in November and May), with each version being supported for 18 months after release. This fits in well with an “annual” upgrade policy and provides a good degree of overlap to allow for deployment testing.
Hi everyone here! :cheer:
Tim, the only thing I can advise you is to use qualitative CRM software. Our company uses online crm products for a long time and has no problems or questions in this sphere. Hope it will help you!
Unfortunately such systems aren’t an option for me, I require a high degree of customisation and these online providers either won’t do the customisation, or the price is so high it’s not economic. I’ve used Salesforce for an unrelated project and I can say with some certainty that implementing a Salesforce based solution would be impossible for me. At least one of my projects requires full control of the underlying hosting platform for confidentiality reasons, so any form of 3rd party cloud hosting is a no go, regardless of customisation issues.
Major point upgrades tend to clobber/break the customisations, so they need to planned for and tested, which is why I care about the software lifecycle.
Bumping this topic back up, since I’ve still not seen anything resembling a product life cycle announcement and the references to 7.6 as an “LTS” release seem to have vanished as well. I need to make a decision in the next few days which version of Suite to upgrade to this summer and there is still no information on what is supported and for how long. After this summers upgrade, I will only be doing minor point release upgrades until Summer 2017 when the next major upgrade of the systems I support will occur, so knowing whether to go for 7.6 LTS (if it is still an LTS release!) or 7.7 is very important.
