I've decided to add a release to the Road Map. This will be a supplemental release to fix some critical problems that are in the 0.9.10 release. Several privileges and user bugs prevented Clay sites to operate correctly, which also prevented me from opening up clay-project.com and upgrading this site.
The supplemental release will be come tomorrow, 29 May, and will be 0.9.15 (Clay 1.0 Beta 2). Clay 0.9.20 is still scheduled for 21 June and has been changed to Beta 3 on the road map.
You can download or clone the latest version of Clay from our GitHub repo: https://github.com/clay/clay.
I'm happy to annouce the first official release of Clay. The official web site is not yet online, but it will be coming soon.
This release is considered Clay 1.0 Beta 1, but labeled 0.9.10 for tracking purposes. Visit Clay's Github repo. While documentation is scarce at the moment, it is a key focus of development between now and next month's Beta 2 release.
Clay 0.9.10 (1.0 Beta 1) is scheduled for release on the 17th of this month, just a few days away. I've been pushing in bug fixes that crept in from me not using Linux for a while. I've been testing on this server using the deployment of Clay-Project.com as my test bed. Clay-Project.com will also open up on Friday.
This first release is kind of bare, in terms of content applications, but it is mostly for testing installation and configuring. Likewise, next month's release will be for testing the upgrade process. Along the way I will be adding some applications. I've been trying to finish the Pages app, for Clay-Project.com, and the Menu service will follow closely after that. Not all applications in the repo will be released, but are available from the master branch of course. The first release may only have the Vision theme, depending on how much time I have between now and Friday. The Vision theme will also be featured on Clay-Project.com, as well as here once I have this site migrated to the release version (probably by the end of the weekend, if not sooner).
It's been a long time coming, but it's looking like I will finally have a first release. Hopefully the forward momentum and a little publicity will bring in some users and maybe even some developers. More to come, but as of now the 17th looks like the day.
I'm currently working on updating the site to the newest version of Clay. I've run into some problems that have been caused from using Windows and not having a test environment on Linux lately. I'll hopefully get those ironned out today.
I'm going to launch a test site for Clay-Project.com and then I'll migrate this site over to that code base, once I know everything is working.
There's shouldn't be any downtime for the update, but consider this a heads up just in case.
Not the IDE I talked about earlier, this one is in my house :) I've been setting up virtual machines on my laptop to use, instead of testing everything in Windows. I also have 4 Raspberry Pi's that I will be using for various server needs in my house, but I haven't started that part yet. My goal is to eventually use only the Pi's for testing and just write the code on my laptop. But, I'm also using all of this to test for scaling and different ways to set up servers for various purposes. Developing on Windows is kind of limiting and I hadn't realized that until I began contributing to some other open source PHP projects here lately. Eventually I plan to move the VM's to a desktop and stop being so mean to my laptop, but my desktop is currently down for the count.
I've been pushing forward with Clay's new release cycle and planning the development path toward Clay 2.0. In about a week I'll be releasing the first public download of Clay and continue prepping for the 1.0 release in August. I mostly consider 1.0 to be finished, it needs documentation and a few important application features, but at this point I'm more concerned with a stable core than features that can be added at any time. With that being said, I plan to round out some of the major needs before August and plug in as much as possible during the monthly release cycles from there out.
Looking ahead, I have some really nice plans for Clay 2.0 and 2.5. It's difficult not to dive in and start making changes, but I'm going to spend a lot more time planning this time around. My hopes for Clay 2.0 are to strengthen the way applications interact and build in several things that will improve Clay for the user and the developer. The biggest addition being, of course, for the developer. The plan is to build in an integrated development environment (IDE) that will act as a development and project management tool.
Clay's IDE will be based on an existing web-based IDE or system and I haven't decided yet how much I went integrate it into Clay's core or if I will try to keep it as native as possible. What I would like is an IDE that can be used to write and edit code on the server side in a sandbox, deploy a test version when needed, and then deploy a live version to be public on the site. It should be able to support multiple hosts for deployment and a patching system for rolling out updates. The IDE should support Git and be able to do all of the main functions of a Git client. It should also have project management features, such as shared tasks and collaboration.
One of the key components of my desired IDE is the ability to manage multiple projects that are local or remote. I'm not only doing this to help Clay's development, the idea is to have a project management environment built into a web site that can be used for anything. But, with that being said, the IDE should provide a strategic advantage over other systems and allow site migrations and upgrades to be done nearly entirely on-site. I know a lot of CMS' are beginning to build in more editting tools for the server side code, but the goal for Clay 2.0 is to make local development obsolete and to provide the ability to write the code on the servers it will be used on.
For Clay 2.5, I want to take development to another level and provide a way to create applications and themes from within the Clay, without having to write a majority of the code behind them. Using wizards and user input, the user should be able to build an application or theme from their web site and use the IDE for editting as needed. A built in package manager will allow users to share apps and even use eachother's apps as templates when creating new ones.
Well, those are some of the plans I have for Clay over the next year or so. There are a few other things I want to do, but I've mentioned a lot of those before or should probably keep a few surprises at least.
Now that I have a foundation for the Clay project's release roadmap, I'll starting filling in some plans the milestones will hopefully implement. Clay 1.0 is mainly a cornerstone release, not a lot of new features will be added between now and then. It's missing a lot of features I have been wanting to add, but most of those are applications that will be worked in through the regular release cycles.
Here's the unofficial breakdown of changes to come:
- 1.0 - Between now and the August 1.0 release, I'm mainly plan to tackle documentation and making Clay easier to learn.
- 1.1 - By December I'd like to have some key features built in that are lacking from the Core, such as hooks and interactions between applications. I also plan to have more applications and themes included in the regular release.
- 1.5 - This release, planned for February '14, will include a built in development environment and focus on completing the 1.0 series.
- The last major release of 1.x, releases working toward 2.0 begin here.
- 1.6 - The first release toward 2.0, a new application object and working toward generation applications from within Clay's built in development environment.
I've created a Google Doc containing the Clay Development Roadmap. It can be viewed here:
It's still a work in progress...
I'm in the process of putting together a roadmap for regular Clay releases. I think having a public release schedule will provide enough motivation to work on it more frequently than I have, with possibly fewer gaps in development, Lately I haven't been able to work on Clay a lot, but I should be able to now that things are settling down for a little while. There's a lot of work to be done toward an official site and things like that, so most likely the initial releases will just be posted here and on GitHub, but I may surprise myself and get Clay-Project.com up earlier.
Right now I'm looking at a June alpha followed up with a beta close behind. From there out it will be mostly beta releases with sporatic alpha versions, depending on the code state and the kind of changes being implemented. I plan to do a full version update once a year, with a 0.5 increment every 6 months. Stable releases will be released quarterly, along with a schedule for the following quarter's beta releases.
The part I'm trying to figure out is mainly the increments between x.5 and xx.0. The x.5 release will be a final release for x.x, with x.6 being the beginning of the roadmap toward xx.0. It's kind of confusing, but the purpose is to maintain x.5 as stable and move on toward xx.0 on a regular release cycle. For instance, 1.5's repo would be cloned into 2.0 and the development would shift to the 2.0 branch, which would really be 1.6 to 2.0. The 1.5 branch would be preserved for bug fixes and maintainence updates. Basically, x.0 and x.5 would be released once a year each, being used as long term support releases, while any 0.1 increments in between would be a beta for the next LTS.
I hope to do a good review of the code and my private roadmap and release an updated plan next weekend.
I've been prototyping Objects, which is similiar to a node in Drupal or Dynamic Data in Xaraya...to an extent. Objects builds on the Data Objects library and adds the persistent data backend that it was lacking. The idea is to provide input and output interfaces for a developer or admin to build custom applications. I say admin, because the way the objects connect allows you to plug in functionality directly into an input or output mechanism, without adding any code. In simplest terms, it's a hook - an application provides a property that performs some type of functionality and you hook that functionality into whatever you want (within reason). The most obvious use of Objects is for forms, where you want a user to input a date, so you plug in the date field property and allows the user to actually pick a specific date from a calendar. On the output side, after the date is input, the output side will allow the admin to format the date in a particular way or use it within another property for some other type of output, such as getting the weather for today's date.
That's just an example. I plan to implement different sources for input, such as user, database, remote, etc, which means there are a lot of other options that then come to the table. I'm hoping to have Objects in a stable beta within the next couple of months.
A lot has changed since my last post. I've moved to Italy (awesome!) and started working here. I love Italy, by far the most beautiful place I've ever lived. The food is awesome, the wine and beer is really good (and cheap), and it has already been a life changing experience. I can't wait to do some travelling and see the as much of Italy and Europe as I can.
"The FCC proposes buying back spectrum from TV stations that would allow for what theWashington Post is dubbing "super wi-fi," as the commission wants to cover the country with wide-ranging, highly-penetrative networks. Essentially, you can imagine the proposal as covering a majority of the country with open-access data networks, similar to cell networks now, that your car, tablet, or even phone could connect to. That means no one is ever disconnected, and some folks–especially light users and the poor–could likely ditch regular Internet and cell plans altogether."
One of my concerns about this is government control. If the FCC was serious about this they would remove fees charged to ISPs and give them spectrum instead of charging millions of dollars for it. I'm all for public Wi-Fi, but only if there is a barrier between the users and government censorship or snooping - although I realize that barrier is paper thin.