Closed (fixed)
Project:
Chaos Tool Suite (ctools)
Version:
7.x-1.0-rc1
Component:
User interface
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
8 Dec 2011 at 08:29 UTC
Updated:
12 Apr 2012 at 21:03 UTC
There's no release cycle in ctools such an important module -- which should always use release version than dev("-dev branch for the D7 port. NOT functional yet!") in production.
Like as drupal core, it would release a new minor version in the end of every month if issues were commit.
Comments
Comment #1
rogical commentedProposal: Create a predictable schedule around Drupal 7 point releases
Keep us from struggling with release and dev please.
Comment #2
bojanz commented@rogical
What complicates the idea is that ctools releases usually need to be synced with Panels and Views, to assure everything works correctly. Additionally, creating a release of such an important module is a lot of work, due to an influx of opened new issues (half of which from users who forgot to clear cache), etc.
Still, since ctools is pretty stable now, and there's been a Views release recently, we could at least have an RC2.
Comment #3
merlinofchaos commentedMy schedule is not such that I can guarantee a cycle. I'm sorry, but the way things are, I'm more or less always overwhelmed. And as bojanz comments, synchronizing with Panels is often important, though luckily that has become less of a big deal in the last few months as the two have stabilized.
I am working on a new CTools release in the near future, however.
Comment #4
videographics commentedI agree that it's impractical to set a timetable for releases in situations like this, but it's also important to keep projects from carrying in indefinitely in a constantly evolving state. While I have great respect for the developers and great confidence in this module (even the dev version), I remain uneasy about having so many of my modules dependent on code which is (by definition) constantly in flux. I'm always asking myself, "Which dev release of ctools did they develop and test this module with?". This is not so good.
I completely understand the perfectionist mentality but are the open 'critical bugs' for dev really showstopers relative to the sum of the issues discovered with rc1 since it was released 6 months ago? Is ANYONE still using rc1?
Comment #5
rogical commentedYes, that's also what I want to say.
I'm sure many users would install the release version first, and when encounter big issues/bugs they will need to switch to the dev version.
However, install a dev version on a production site is more or less not a good thing, and seems not a professional way.
Especially for such a important module, I'd like always to use release version, while only use dev on small modules.
Also we can see the D7 release cycle now, when there're important updates, it would release a new version on the month-end.
Comment #6
merlinofchaos commentedNo, the problem is that between client commitments, personal life, and medical issues, I haven't had time to even do the necessary patch review.
The "needs review" queue is over one page long. I'm desperately trying to find the time to go over this so I can evaluate how critical they are, but it hasn't happened yet. I'm very sorry, but there just aren't three of me right now. The CTools suite is my highest priority, but I've also had to focus on what my clients have contracted me to do. And this is totally part of it, but it hasn't made it into my queue yet.
Comment #7
videographics commentedI'm very sorry. I really didn't mean to imply that you should roll a release before it's ready – or before you're ready. I also understand there are now SO many modules dependent on ctools now that it has to be right. And, I certainly didn't mean to suggest you should compromise your work commitments or personal life to get this done. We all have our priorities.
I guess the main thing is that this issue just got me thinking about the long-term health of projects like this. With an ever increasing number of complex external modules dependent on different parts of this project, over time it's naturally going to become increasingly difficult to roll releases with 'everything' stable all at once. Has there been any discussion about the possibility of restructuring ctools to make it more manageable in the long-term? I assume there are good reasons for why ctools is a 'suite' and not a bunch of separate projects. But, I remain curious about what opportunities exist for spinning off various parts of it. I'd think if even only some smaller parts of it could be spun off, it would reduce the pressure to get 'everything' right all at once. Do I just not know what I'm talking about?
Comment #8
gregglesThere are currently about a dozen criticals and about 22 major issues (excliding NMI in both cases).
Seems like it's roughly time for a new RC.
Comment #9
Letharion commentedI want to point out to everyone who cares about the Ctools project, that it doesn't need to take a lot of time to help maintain the issue queue. As merlin points out, a significant portion of issues are opened by people that forget to clear the cache. Just identifying these issues, and asking users to try after clearing the cache again, would alleviate a great deal of burden from the very few people that maintain the module.
Comment #10
mgifford+1 for rc2
I just came here after realizing that the bug I was tracking down was fixed in September in dev.
Comment #11
Ashlar commented