This week we tagged the long-awaited 2.0.8 release of ng-grid.
Then we had an immediate goof in the bower package and had to release 2.0.9 (and then 2.0.10).
8 months between releases and then we have 3 in 3 days. Go figure.
2.0.9 is a maintenance release that incorporates many pull requests. We will continue to issue 2.0 maintenance releases as PR's come in that address major issues, but there will be no active development on 2.x by the core team.
We also made the difficult decision to close all the open issues related to 2.x. We know, we know.... But, would you rather have 300 open issues that no active developer was looking at; or would you rather see 30 issues that are being actively worked on? Reducing the noise is a key to getting a better handle on the project. There's a reason the backlog got as big as it did in the first place. We're not happy about this either, but with the present project team it's the best option we have for being able to actively manage the project going forward.
ng-grid was started about 2 years ago by two passionate developers, Tim Sweet and Jonathon Ricaurte, who wanted the speed and features of Slickgrid for use in AngularJS applications. Since it was one of the first grids for Angular, it was used by a lot of developers, including the current development team. It was an easy to use grid that was also incredibly powerful.
Roughly 10 months ago, both of the original developers moved on to other responsibilities and were not able to spend much time with ng-grid. This caused a number of problems:
- Brian, Shane & Rob
Then we had an immediate goof in the bower package and had to release 2.0.9 (and then 2.0.10).
8 months between releases and then we have 3 in 3 days. Go figure.
2.0.9 is a maintenance release that incorporates many pull requests. We will continue to issue 2.0 maintenance releases as PR's come in that address major issues, but there will be no active development on 2.x by the core team.
We also made the difficult decision to close all the open issues related to 2.x. We know, we know.... But, would you rather have 300 open issues that no active developer was looking at; or would you rather see 30 issues that are being actively worked on? Reducing the noise is a key to getting a better handle on the project. There's a reason the backlog got as big as it did in the first place. We're not happy about this either, but with the present project team it's the best option we have for being able to actively manage the project going forward.
ng-Grid Project - A History
To give you some perspective on why things have happened as they have.ng-grid was started about 2 years ago by two passionate developers, Tim Sweet and Jonathon Ricaurte, who wanted the speed and features of Slickgrid for use in AngularJS applications. Since it was one of the first grids for Angular, it was used by a lot of developers, including the current development team. It was an easy to use grid that was also incredibly powerful.
Roughly 10 months ago, both of the original developers moved on to other responsibilities and were not able to spend much time with ng-grid. This caused a number of problems:
- A huge backlog of issues
- Lots of unfixed bugs
- Zero communication coming out of the project
- Fear / Uncertainty / Doubt
Around September of last year, efforts were made to get the project going again. The original developers, some active community members, and the Angular UI project overlord met in a hangout to discuss the situation. The results:
- Current grid had some fundamental flaws that were causing a lot of the bug reports
- A rewrite was the best alternative
- Nobody had time for a rewrite
- New core team members were needed
- ng-grid name implied that it was a Google supported project. A more proper name is UI Grid
The project sat still while we reformed and looked for time outside our busy work lives to commit to the project. Appeals were made several times for development help, but try as we might, only a few people stepped up.
Finally, around January, the 3.0 branch really started getting traction. Brian spent a lot of time getting a core code base and all the tooling in place. Hours and hours were spent just getting the build/test/deploy tooling ready. This is the part of Open Source development that most people never consider but it's a vital step for a strong project foundation.
Currently, the project has two main developers and one project coordinator. None of us can spend more than 10% of our weekly time on this project.
The project needs more developers! Angular developers, please, consider helping out. It's a challenging project that has the opportunity to be one of the best data grids out there (period) and the best one on AngularJS, the the best web application development platform around.
3.0 Philosophy
Lessons learned from the 2.x code base led us to the following decisions.
- Testable code from the start.
- The application must be broken up into feature modules.
- Angular modules/service/directives would be the foundation for the feature modules.
- Easy upgrade path from 2.x. Support 2.x gridOption names as much as possible.
- Works on all platforms
- Drop support for IE8. We just don't have the resources to worry with IE8 compatibility.
- Only dependency is Angular 1.2 and higher.
3.0 Roadmap
- Core UI Grid:
- complex bindings (done)
- row and column virtualization (done)
- row selections (in process)
- sorting (done)
- filtering (in process)
- Inline editing module (done)
- Column resizing module (done)
- Cell Navigation module (done)
- Column Pinning (in process)
- Column Moving (in process)
- Grouping
- Row Moving
- SubGrids
We plan on doing a 3.0 RC as soon as column pinning, row selections, and filtering are complete. The first 3.0 will not include grouping feature unless some superstar steps forward in the next month and completes that feature. Grouping will follow a 3.0 release as quickly as we can get it done.
How you can help
Test 3.0 out for us. Some of us are using it internally in our organizations. It's not yet perfect, but it's getting better every day.
The best thing you can do is become a feature developer. The progress that we've made with a skeleton crew is remarkable, but what we really need right now is for some people to come on-board and pitch in to get us to a point where we can confidently put this new version in front of developers.
- Brian, Shane & Rob