Is there a CB 5 underway? There used to be a milestones, etc. section on the Atlassian site that could be monitored to see different branches and what the team was working toward. I don’t see any alternate dev branches on GitHub and am really just more curious than anything else as to the plans - if any - moving forward.
We do have a roadmap we created for ColdBox 4 that had future items on it. Right now, ColdBox is a very mature and stable framework. Much of our current work has spun off into the modules surrounding it as well as tools like CommandBox and ContentBox.
Are there any major features you’d like us to think about.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Thanks Brad. As I said, I was more curious than anything. There was a post on the FW/1 blog yesterday re: v4.0 coming up with mentions of 4.5 and 5.0, etc. so it got me thinking about where Coldbox was headed.
No problem.
We actually released or 4.X roadmap last year, you can see it here: https://drive.google.com/file/d/0B_65i6I500NiQ0NFQ1Atbk9Tb2M/view?usp=sharing
As you can follow it, we pretty much nailed almost everything in our 4.x series roadmap. We are still working on some items in it, but it has been our driving force. I can estimate that we would do a 5.X roadmap after Into the box this year.
Thanks Luis (and Brad) - that’s good to hear!
Thinking about it, one area I was wondering about was plans for support for the new lucee dialect (especially with both of you intimately involved with that project)
That’s a good question Andrew, and one we’ve discussed a little internally. That question can mean one of two things, so let’s clarify:
- Write a second version of the entire framework that is 100% Lucee dialect inside (which also begs whether it should be extendable via CFML)
- Keep the core Coldbox framework written in CFML for portability, but allow it to be extended via Lucee with Lucee views, handlers, etc. This would involve parts of the code that checks for file extensions, etc.
To be honest, no one has actually asked for either of those yet so demand is little. The first option would be a huge amount of work and would double the overhead of maintaining the framework. As the Lucee dialect currently always ships alongside CFML support, I would say there is little-to no usefulness for #1 other than the “coolness” of doing it.
Number 2 however I think would be fairly simple to accomplish and would have a fair amount of usefulness for people who want to play with the new Lucee dialect inside of ColdBox. I would personally be a fan of giving this a go, and would encourage anyone who wanted to take a stab at it to send over a pull if they can get it working. I’d start by searching the codebase for any reference to “.cfm” and “.cfc”. We’d also need to double check if a Lucee class can extend a CFML component. It may be necessary to create some Lucee-based base classes or rely on virtual inheritance.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Oh, also just to add an extra bit for those not following the Lucee dialect closely. LuceLang is still in an experimental stage and likely to change in the future. It will ship in Lucee 5, but will be disabled by default. Any significant work done to support Lucee will likely need to be kept in sync with LuceeLang as it solidifies.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com