Answers.Body: <p>One of the challenges of such a large open source software project is that it is in a constant state of flux - this is particularly true of non-lts versions (i.e. for extra stability v4.6.* is recommended). Sadly, breakages do occur. The community definitely recommends having a staging server to test with and taking backups of databases so that you can roll-back if you needed to (as you said you'd prefer to).</p>
  
  <p>"Challenging the company" is less useful than, say, contributing unit tests that test key functionality that you never want to break.</p>
  
  <p>JohnFF</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-09T17:34:13.577Z
Answers.LastActivityDate: 2016-04-09T17:34:13.577Z
Answers.UserDisplayName: JohnFF
Answers.Body: <p>CiviCRM does not have a "Known Issues" report per se, and I do not believe I have ever seen such a section in the announcement of a new release. What it has is <strong><a href="https://issues.civicrm.org/jira/browse/CRM/" rel="nofollow noreferrer">JIRA</a> (issues.civicrm.org)</strong>, which provides many tools for tracking problems great and small. </p>
  
  <p>This is where you report and track specific bugs; for example, <a href="https://issues.civicrm.org/jira/browse/CRM-17968" rel="nofollow noreferrer">CRM-17968 scheduled emails not processed</a> is reported to be fixed as of 4.7.4. But you are also given many tools for navigating the issues according to severity, resolution progress, and anticipated correction. You can see <a href="https://issues.civicrm.org/jira/browse/CRM/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel" rel="nofollow noreferrer">planned releases</a>, the <a href="https://issues.civicrm.org/jira/browse/CRM/?selectedTab=com.atlassian.jira.jira-projects-plugin:changelog-panel" rel="nofollow noreferrer">Change Log</a> of which fixes were applied to which versions, and <a href="https://issues.civicrm.org/jira/browse/CRM/fixforversion/16890/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel" rel="nofollow noreferrer">recent progress</a>.</p>
  
  <p>Broken functionality is not always detected during pre-release testing. I think if the core development team knew critical functionality was broken, they would fix it rather than include it in a report. Helping test the beta versions, either on your system or on demo.civicrm.org, will help prevent the software from going to release with major unresolved problems.</p>
  
  <p>Related: <em><a href="https://civicrm.stackexchange.com/questions/2653">What should I do if an issue is marked as fixed in JIRA but it is still occurring?</a></em></p>
  
  <hr>
  
  <p>Obligatory lecture: the <a href="https://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Upgrades" rel="nofollow noreferrer">installation and upgrade guide</a>, for one, emphasizes that you should back up your databases before attempting an upgrade. Your organization should have its own change control protocols for releasing new software to make sure that critical functionality does not suffer, and the system should be tested thoroughly before moving it into production. Your inability to roll back to 4.5.6 is not the fault of the developers.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-06T04:29:46.137Z
Answers.Text: Partly what I was worried about in posting this was that the idea or onus for breakage would be pushed back onto the users by anyone responding. OMG, "it's your fault for installing an upgrade!" That is what I think you are saying. I am an almost retired software engineer working for a very small non-profit. Personally, I have never been allowed to ship bugs -- really. Backing up the databases 8 or 9 versions ago does not help in the case of CiviCRM. I have made backups every step of the way. By the way, the testing should be done before versions are released -- and not be deferred to users.
Answers.UserDisplayName: P a u l
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-06T04:37:52.510Z
Answers.Text: If "Known issues" is another way of saying breaking changes then so be it. I am challenging the company to up their game.
Answers.UserDisplayName: P a u l
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-06T04:40:29.387Z
Answers.Text: No you are cool
Answers.UserDisplayName: P a u l
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-06T05:01:56.033Z
Answers.Text: Sorry I voted you down but I then voted you as the answer :+> I am not a bad guy.
Answers.UserDisplayName: P a u l
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-06T18:06:48.250Z
Answers.Text: Re: "I am challenging the company to up their game." <humour>Yeah, with those extortionate licensing fees we pay, it should be perfect.</humour> CiviCRM is a community open-source project.  There is no large company backing it with a dedicated QA team.  It seems subjectively that 4.7 has produced a large crop of bugs and it's a fair question to ask how we can improve the quality before release. But "challenging the company" is looking in the wrong direction: it is a community effort - ie us!
Answers.UserDisplayName: Aidan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-07T05:06:48.847Z
Answers.Text: To add to Aidan's comment, there has been a very active discussion on the developer mailing list the last week or so about ways to improve the testing and release cycle. There seems to be general consensus there that improving quality control for future releases needs to be a big priority right now.
Answers.UserDisplayName: Allen Hutchison
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-09T17:00:48.850Z
Answers.Text: @Aiden -- Seems like they need to hire someone good at writing grant proposals. There might be funding out there from a foundation. I will continue to post about problems, and solutions if I find them.
Answers.UserDisplayName: P a u l
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-06T03:50:26.997Z
Answers.LastActivityDate: 2016-04-06T03:50:26.997Z
Answers.LastEditDate: 2017-04-13T12:53:13.167Z
Answers.UserDisplayName: choster
Body: <p>We seem to have had several serious instances of loss of functionality when installing newer versions of CiviCRM. A lot of software projects have a list of breaking changes as each new version is released. Without an organized official list, I am afraid the developers might not actually be aware of breaking changes. The main losses (the ACL one filed as a bug) are:</p>
  
  <ol>
  <li><p>ACLs no longer work with smart groups (this was working for us as of ~4.5.6).</p></li>
  <li><p>ACLs don't even work with static groups anymore.</p></li>
  </ol>
  
  <p><strike>3. Bulk email, cron + CivicMail, no longer works. The cli.php cron method no longer works. We had bulk email working as of version ~4.5.6 using cli.php. I spent hours working with wp_cli recently on 4.7.4 and I can't get that to work either.</strike></p>
  
  <p>I would go back immediately to v4.5.6 if I could, but the schema changes to the database prevent this.</p>
  
  <p>Edit: I fixed #3 -- I was missing the 'view all contacts' permission for the cron user.</p>
  
Tags: <wordpress><4.7><documentation>
Title: Where is a list of breaking changes published for each new version?
ThreadText: # Where is a list of breaking changes published for each new version?
  
  (Asked by: username_0 on 2016-04-06)
  
  We seem to have had several serious instances of loss of functionality when installing newer versions of CiviCRM. A lot of software projects have a list of breaking changes as each new version is released. Without an organized official list, I am afraid the developers might not actually be aware of breaking changes. The main losses (the ACL one filed as a bug) are:
  
  1. ACLs no longer work with smart groups (this was working for us as of ~4.5.6).
  2. ACLs don't even work with static groups anymore.
  
  3. Bulk email, cron + CivicMail, no longer works. The cli.php cron method no longer works. We had bulk email working as of version ~4.5.6 using cli.php. I spent hours working with wp\_cli recently on 4.7.4 and I can't get that to work either.
  
  I would go back immediately to v4.5.6 if I could, but the schema changes to the database prevent this.
  
  Edit: I fixed #3 -- I was missing the 'view all contacts' permission for the cron user.
  
  **Tags:** wordpress, 4.7, documentation
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2016-04-06. Score: 3 | Accepted answer
  
  CiviCRM does not have a "Known Issues" report per se, and I do not believe I have ever seen such a section in the announcement of a new release. What it has is **[JIRA](https://issues.civicrm.org/jira/browse/CRM/) (issues.civicrm.org)**, which provides many tools for tracking problems great and small.
  
  This is where you report and track specific bugs; for example, [CRM-17968 scheduled emails not processed](https://issues.civicrm.org/jira/browse/CRM-17968) is reported to be fixed as of 4.7.4. But you are also given many tools for navigating the issues according to severity, resolution progress, and anticipated correction. You can see [planned releases](https://issues.civicrm.org/jira/browse/CRM/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel), the [Change Log](https://issues.civicrm.org/jira/browse/CRM/?selectedTab=com.atlassian.jira.jira-projects-plugin:changelog-panel) of which fixes were applied to which versions, and [recent progress](https://issues.civicrm.org/jira/browse/CRM/fixforversion/16890/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel).
  
  Broken functionality is not always detected during pre-release testing. I think if the core development team knew critical functionality was broken, they would fix it rather than include it in a report. Helping test the beta versions, either on your system or on demo.civicrm.org, will help prevent the software from going to release with major unresolved problems.
  
  Related: *[What should I do if an issue is marked as fixed in JIRA but it is still occurring?](https://civicrm.stackexchange.com/questions/2653)*
  
  ---
  
  Obligatory lecture: the [installation and upgrade guide](https://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Upgrades), for one, emphasizes that you should back up your databases before attempting an upgrade. Your organization should have its own change control protocols for releasing new software to make sure that critical functionality does not suffer, and the system should be tested thoroughly before moving it into production. Your inability to roll back to 4.5.6 is not the fault of the developers.
  
  > **Comments:**
  > **username_0**: Partly what I was worried about in posting this was that the idea or onus for breakage would be pushed back onto the users by anyone responding. OMG, "it's your fault for installing an upgrade!" That is what I think you are saying. I am an almost retired software engineer working for a very small non-profit. Personally, I have never been allowed to ship bugs -- really. Backing up the databases 8 or 9 versions ago does not help in the case of CiviCRM. I have made backups every step of the way. By the way, the testing should be done before versions are released -- and not be deferred to users.  
  > **username_0**: If "Known issues" is another way of saying breaking changes then so be it. I am challenging the company to up their game.  
  > **username_0**: No you are cool  
  > **username_0**: Sorry I voted you down but I then voted you as the answer :+> I am not a bad guy.  
  > **username_3**: Re: "I am challenging the company to up their game." <humour>Yeah, with those extortionate licensing fees we pay, it should be perfect.</humour> CiviCRM is a community open-source project.  There is no large company backing it with a dedicated QA team.  It seems subjectively that 4.7 has produced a large crop of bugs and it's a fair question to ask how we can improve the quality before release. But "challenging the company" is looking in the wrong direction: it is a community effort - ie us!  
  > **username_4**: To add to username_3's comment, there has been a very active discussion on the developer mailing list the last week or so about ways to improve the testing and release cycle. There seems to be general consensus there that improving quality control for future releases needs to be a big priority right now.  
  > **username_0**: @Aiden -- Seems like they need to hire someone good at writing grant proposals. There might be funding out there from a foundation. I will continue to post about problems, and solutions if I find them.  
  
  ---
  
  ### Answer by username_1 on 2016-04-09. Score: 0
  
  One of the challenges of such a large open source software project is that it is in a constant state of flux - this is particularly true of non-lts versions (i.e. for extra stability v4.6.\* is recommended). Sadly, breakages do occur. The community definitely recommends having a staging server to test with and taking backups of databases so that you can roll-back if you needed to (as you said you'd prefer to).
  
  "Challenging the company" is less useful than, say, contributing unit tests that test key functionality that you never want to break.
  
  username_1
  
  
  ---
  
  