search

lonnieezell / Bonfire

Jumpstart your CodeIgniter web applications with a modular, HMVC-ready, backend.
http://cibonfire.com
1.39k stars 524 forks source link

Milestone 0.7 "Past due by 4 months" #789

Closed SethArchambault closed 11 years ago

SethArchambault commented 11 years ago

I'm fine with the fact that it's running behind, but it's damned depressing to not have a new due date. 1 more months? 6 more? a year? Whatever it is, it'd be nice to have a fresh date to look to. Thanks!

mwhitneysdsu commented 11 years ago

I think we've seen a significant reduction of activity on the 0.7 release due to a number of factors, not the least of which is @lonnieezell deciding to focus on a 1.0 rewrite (see http://forums.cibonfire.com/discussion/1122/thoughts-on-bonfires-future#Item_1 and https://github.com/lonnieezell/bonfire-reboot).

That being said, thanks largely to the efforts of @sourcejedi I believe the 0.7 branch is very stable at the moment.

I'm thinking that the feature set for 0.7 (see https://trello.com/board/bonfire-roadmap/4f21de254768c8463f09c85b) should probably be cut back, especially given how big the folder layout change turned out to be. Many of the remaining features are either on-going and should have a more distinct cut-off point (i.e. "Improve memory usage" and "Complete set of Guides") or have not made much progress and/or were largely planned by developers that have not had much time to contribute lately.

We also should probably do a better job of using the tools github provides for us to communicate the progress and planned features of a given release. Clearly the Milestones could be a very useful tool in many ways, but we've used it as an issue tracking feature and ignored its other features as a project management tool, including maintaining the due date.

Clearly, I could just knock it forward another 3 months and call it good until it becomes late again, but I think it warrants deeper discussion.

SethArchambault commented 11 years ago

Any insight on how 0.7 compares to the 1.0 rewrite in terms of stability and the future? Seems like at some point developers are going to have to choose between continuing on this repo or switching to the reboot..

mwhitneysdsu commented 11 years ago

I haven't really evaluated the rewrite, yet. Since my job is primarily centered on maintaining an existing site and adding features to that site, I am a little more focused on making sure the system I have works and will continue to do so. This means that for the foreseeable future I am committed to this code base, whether it can remain supported or not.

I don't get the feeling that backwards compatibility for modules is going to be given much attention in the reboot, but I may be wrong in that respect. If it turns out that there may be some potential upgrade path available, I will have to evaluate it in terms of how it compares and what impact migrating an existing site to it will have (on both myself in terms of upgrading existing modules and my site's users).

Clearly these are not the same decisions someone deals with when they are evaluating technology for a new site, and the project being in this kind of flux will have some impact on that process for new developers.

SethArchambault commented 11 years ago

well said, thanks!

SethArchambault commented 11 years ago

Another relevant issue: There are a ton of unlabeled issues here. There are 116 open issues, only 17 of them are attached to the 0.7 label. Perhaps it's time to cull the herd a bit?

lonnieezell commented 11 years ago

Hey guys, first off - sorry I've disappeared lately. I'm changing that and getting back into the game here with the 0.7 work. It's been a while and I'm deeply sorry I basically abandoned the project. That was my bad. I still believe there are portions that need a deep re-write, but we should get a stable 0.7 out the door and figure out how to go from there. I've got some ideas, but that's for another thread.

Since there are a ton of changes by the team (Thanks so much to everyone!) one of the first things that I'm doing as I'm coming back is diving in and trying to get us a decent set of unit tests in place so that at least we know those portions aren't broken. I'm not going to worry about functional or integration tests for the time being. If we can get a decent set of unit tests together, we can maybe start looking into some continuous integration for the project. At the very least, it gets us into a good place to start refactoring code for future releases and know when we break things. :)

After the initial set of tests are done, I'll start tackling any issues that are still open. Of course, if others get to it first, that's alright, also. I won't complain. However, I would like us to start using unit tests more often. So, on bugs I'll be creating a test first to verify then fixing the bug so the test/tests don't fail anymore. I think that's the only way we can ensure a stable base going forward.

Then I'll revamp docs. And then we can release. Do I have a firm time-table? Unfortunately not, at least until I get some more of the tests written. Anyone who wants to help out there, I'm all for help writing tests to get us a decent coverage here. It's kind of tedious work...

SethArchambault commented 11 years ago

Sounds like a great plan to get things ironed out! ..I've got to learn about bonfire's unit testing, haven't written any myself, and some continuous integration sounds like a good idea.

lonnieezell commented 11 years ago

Thanks. We use SimpleTest for the testing suite that has been modified to work with a nice little gui. In the code I pushed last night there's a revised version of the whole thing that I had been working with on the reboot that I brought over. I also created a public file called tests.php which makes it easy to get to without breaking everything. :)

SethArchambault commented 11 years ago

Yay!