“What the dev preview has confirmed for me is that we’re on the right track.” - Derek Allard, EllisLab
That pretty much sums up how things are going with Kaylee (the ExpressionEngine 2.0 Dev Preview). The past several weeks have been filled with feedback from the Developer Preview that we’ve used to shape 2.0’s add-on strategy and make a few key architecture decisions.
Great to hear you guys are making progress, and I’m really looking forward to seeing the Beta. My only concern at this point would be how long we’re going to have to wait, if you’re making architecture decisions now the wait might be longer than I was hoping.
Patience is a virtue…
In a mean time I’ll work with 1.6 which works just fine for me
Completely agree, patience is a virtue. 1.6 works fine for most situations, but it’s hard explaining why we charge clients now, and will quite possibly be charging them another chunk in a few months to upgrade. So for some projects I’d rather try and make the clients wait for 2.0 so we can utilise CodeIgniter — it’s just hard without any idea when it’s landing.
Great to hear you guys are making progress, and I’m really looking forward to seeing the Beta. My only concern at this point would be how long we’re going to have to wait, if you’re making architecture decisions now the wait might be longer than I was hoping.
Please don’t be longer than mid-year.
I wondered if using the word “architecture” was a good idea in the post… as well as the car analogy. In the end I did because I felt it was the most honest description of what’s going on.
Its also turned out to be a word that is used a lot without a specific meaning and it has a rather “epic” ring to it when really it can apply to any decision that impacts the well, “architecture” of the software, regardless of how small or big that decision is.
In this case the types of architecture decisions we made (and may still make during the Dev Preview) are in specific regards to how 3rd party add-ons interact with 2.0. While these are important, “key” architecture decisions they aren’t necessarily time consuming.
These decisions include discussions on where 3rd party add-ons are installed in the folder structure, how certain hooks are used, dealing with language files in unique situations, update notification schemes, how certain types of queries should be written, and other things related to 3rd party add-on development and interaction with EE.
For example, if we decided to change where the actual folder for 3rd party add-ons is, that’s an important decision! Its an architectual decision. Its also a decision that requires very little time to implement. In other words, architectual decision doesn’t necessarily equal huge amounts of time.
Being able to speak with the most active and prolific EE devs informed these decisions. We discovered that in most cases our default assumptions were correct but in a few, the feedback altered our approach for the better. This is exactly the purpose of the preview and the result is a better platform for 3rd party devs. This type of discussion simply couldn’t have occurred earlier in the development process.
None of this is particularly exciting to a general audience which is why I didn’t expand on the nitty-gritty details in yesterdays post. Though given the feedback, I probably should have. Lesson learned!
We plan to do one more round of Developer Preview invitations (in the next week or so) before closing off the Dev Preview and concentrating on the next part of the release phase, the semi-public beta.
Mmmmmmmm…semi-public beta…tasty!
Robin, you have to give us syntax here! Some of us are still relative EE newbies.
This is presents a conundrum. I really don’t want to put a whole lot of money into development at this point, especially if it requires third-party add-ons, if it is going to have to be redone with the new release. On the other hand, there is no telling when the new release will be released. How are others addressing this issue? Are others just waiting, or are they moving ahead not know how much will have to be redone? I would like to move ahead with my project, but I can wait.
This is presents a conundrum. I really don’t want to put a whole lot of money into development at this point, especially if it requires third-party add-ons, if it is going to have to be redone with the new release. On the other hand, there is no telling when the new release will be released. How are others addressing this issue? Are others just waiting, or are they moving ahead not know how much will have to be redone? I would like to move ahead with my project, but I can wait.
Rich
Rich I don’t mean to sound funny on this, far from it but if you can get your site working with the existing ExpressionEngine 1.6.7 and 3rd party plugins etc… then you’re not really very likely to have to re-do anything are you?
I see it a bit like buying a car or a computer, something like that anyway. You might buy the latest and greatest of either of those and then next week a brand new version comes out with great new features. The way I look at buying something like a computer for instance is that I buy the best that I can afford and something which is going to last me quite a while. Even though there are great new versions out you don’t have to purchase them if you can get the existing one to do what you need.
This is exactly the same for ExpressionEngine. If you can get 1.6.7 to do what you need now and your site fully works then why would you need to upgrade?
Usually, what happens with any system, is that changes/improvements are required, either because of changing circumstances within the marketplace, or forced changes in the underlying platform. Support, particularly with add-ons, is lost, and you are forced with a decision to re-write, become outmoded, or live with the problems (often security issues for the hand of the developer). It absolute chaos in Drupal and Joomla land, because of the exact same issues that there are no migration paths between releases. Wordpress, on the other hand, has always provided a very clean migration path between releases, though add-ons and themes to become obsolete. Microsoft, with their operating systems, began this trend which never existed in the mainframe world. The customers would go berserk, if there were not clear migration path for the hundreds of millions of dollars invested in their critical customer systems. Unfortunately, in the PC world, it has become a common practice.
In any case, I am concerned about unnecessary doubled costs to myself due to obsolescence of a system. To me, it would be a waste, if I built a system, with certain costs, and could have saved a significant amount of that cost, and built a better system, simply by waiting a few months. As I said, I do not have to start to build today.
Support, particularly with add-ons, is lost, and you are forced with a decision to re-write, become outmoded, or live with the problems (often security issues for the hand of the developer).
Just for the record, we are committed to supporting the 1.6 branch for quite some time after the release of EE 2, especially when it comes to security related issues. In that sense, it will be an entirely new product.
In any case, I am concerned about unnecessary doubled costs to myself due to obsolescence of a system.
As I’ve said, EE 1.6.7 will not suddenly become obsolete. It shouldn’t have much of an impact on the life-cycle management of your website.
We’ve stated publicly that the 2.0 path is an update, not a migration. If you are using stock EE, or EE with any of the most popular addons, the update should be about as hard as any other version update. Of course there are always unforeseen things that come up, but we are working very hard to minimize those.
I continue to recommend that developers build on 1.6 - it is a proven, reliable system that won’t be going anywhere in the short term, and presents a clear, straightforward update into 2.0 should you choose to take it. At EllisLab we are committed to keeping 1.6 maintained, secure and viable for some time.
