Taking a look at their "idea" page, I found myself nodding along with most of their bullet points (or shrugging and saying "not exactly my preference, but I can see why you'd want that"), until I hit:
Ghost would have cut-off points with major versions,
allowing core developers to remove old code from the
codebase and evolve the platform to allow it to improve.
No one expects an app written for OSX 10.4 Tiger to work
on OSX 10.8 Mountain Lion.
Oh, hell no. Backwards compatibility is way more important than some shiny new feature. When I upgrade my software, I expect it to work better, not break. If I have a working plugin from 5 years ago, why should I have to fight with some pointless API redesign just to get it to work again?
In the real world, people need compatibility more than they need whatever cleanup you're able to do by breaking compatibility. Heck, in many cases you can get both by doing your rewrite but leaving a compatibility layer on top that gives you the compatibility that you need.
I'm so sick of trendy "modern" frameworks like Rails that break compatibility every 5 minutes, and listing breaking compatibility as a major feature is a huge turnoff.
How about focusing on spending the pre-1.0 releases iterating and designing a really good API that will be amenable to backwards compatible extensions, and then sticking to that API and backwards compatible extensions to it for the forseeable future?
How long do you expect upgrades to work before a break in compatibility?
Forever? At least the linux kernel has an explicit goal of never breaking userspace. That doesn't mean other parts of userspace don't break themselves, but the linux kernel has as a development goal to never break binary compatibility for userspace.
It's important to remember that the Kernel is a very small piece of the puzzle that decides whether your 1991 binary works on a system today. The real kicker is whether the glibc versions match, whether X11/Motif will still be around for a while, etc.
But I still admire the kernel for their stance even if it can't solve every compatibility problem.
My last computer retired - 1 month ago. It was more than 5 years old, running Windows XP. XP is still very popular and I would expect it to still be supported and it's 12 years old.
Where did you get your 7 year magic number from?
You can't talk about Windows XP like it's a single, fixed point in the release cycle. XP was released in 2001, giving you your 12 year number, but there were also major service packs released in 2002(SP1), 2004(SP2) & 2008(SP3). The last release of XP was only 5 years ago - more recently than OS X 10.4
Of the new software that still claims XP compatibility, much of it requires SP3.
Yes, it's free but that doesn't mean it's painless. Going to SP2 and SP3 broke backwards compatibility with some drivers and software. It increased the RAM/CPU requirements for running the OS comfortably. They weren't just harmless stacks of collected bug fixes.
Microsoft products receive 5 years mainstream support and 10 years extended support. XP is currently supported for organisations who purchased extended support, but only because there was extraordinary demand for it. It ends in just under 6 months from now.
Unless you're a large organisation paying a lot of money, you aren't likely to get 5 years of support for a particular version of most products.
Especially for a young project, I think this is ok. You don't want it to be set in stone too early. Once there is an established ecosystem around Ghost, there will be a lot more pressure to keep it stable.
Even better than that is pressure to keep addons/plugins/whatever up to date.
I think there's some good precedence for that with Firefox who (still?) deliberately broke all their extension compatibilities on every release, and contrary to that Wordpress who've led to a fully automated exploit ecosystem.
I don't know about Firefox doing that on purpose, but the addon that I've written (Link Exposé) has seen several releases of firefox (19.* to 24.*) without having to do an (api) "update". It's written using the new jetpack SDK (now "Add-on SDK") - and there is a commitment to keeping that api stable.
Nope, this is exactly what happened to Wordpress. As a senior Wordpress developer who deserted the platform after giving up, I can safely comment on your views:
#Supporting older versions is a pain. Supporting all features in older versions AND newer versions to work together is an even bigger pain. Example: Wordrpress.
#Compatibility for older version leads to bloated code, with too many legacy variables, too many points of failure. Example: Wordpress.
#Evolution of any software requires that it discards old ideologies and embraces the newer ones. The ones that don't do, tend to drift away from the main goals. Example: Wordpress.
Wordpress was started with the exact same intention as Ghost and yet, what you are left with now is a half-baked unstable CMS, and a half-baked blogging platform that breaks old plugins with each upgrade.
If you want to embrace progress, then you must embrace C.H.A.N.G.E. And this is not just for software.
That's hilarious, it's a major feature I want from a blog and I came to the comments to advocate. It's one of the best things about Drupal, for instance.
I want a frozen codebase that only worries about critical security updates.
In the real world, you will break your site by adding new plugins every few months. The site will break. I get a stable codebase and I sit on it.
Development causes bugs! Milestone releases are what I want.
> In the real world, people need compatibility more than they need whatever cleanup you're able to do by breaking compatibility.
Here's the thing: if you're a user that needs compatibility don't upgrade! (not an option with most blogs) If you're always adding new functionality and plugins to your blog, things will break. If your business needs constant new web technology updates, use a real CMS and fix them when they break. They will break, they always break.
Compared to WordPress, which touts backward compatibility as a strength, yet still manages to break itself in some way, shape, or form with every new release?
I'm not necessarily comparing to WordPress. What I'm saying is that they should be going in the other direction; towards better backwards compatibility.
Of course, one way to achieve this is less reliance on add-ons, so you have less API surface to expose. Having a usable WordPress install relies so heavily on add-ons that it's kind of pointless to consider WordPress alone.
> In the real world, people need compatibility more than they need whatever cleanup you're able to do by breaking compatibility.
Time and time again, rolling software has proven to be more secure than static releases. A plugin from five years ago that hasn't been maintained in that time is probably going to hurt you a lot.
Rolling software is better achieved with better backwards compatibility than it is with constantly breaking API changes.
When you have constantly breaking API changes, and then someone has an essential plugin that's unmaintained, then they're a lot more likely to stay with your old, buggy, insecure base package, rather than finding someone who knows how to update their plugin (remember, most users aren't programmers, and most have installed plugins for a reason).
What you do is try to minimize the API surface that plugins have so it's easy to maintain backwards compatibility, and minimize the impact that older plugins can have by keeping them reasonably well isolated.
I'm not much of a wordpress user, so alas can't provide good wordpress examples, but this is really a software in general thing. Run a Linux box? How many times have you upgraded OpenSSL in the last five years?
For that matter, most apps written for Tiger should work on Mountain Lion, with the important exception of PowerPC apps - but that was a matter of maintaining library support for an entire architecture, and anything written for the Intel release of Tiger is fine.
The other way around is different, of course, as as a huge number of new APIs have been added since then.
Should Apple not have gone to a 64-bit operating system because of hardware like the first MacBook Pro, with a 32-bit processor and RAM that maxed out at 2GB?
This is the reason why my own blog is static files of Markdown for the content, combined with a tiny blog engine, all in the same git repo - I just don't want to deal with the pain of some upgrade suddenly breaking stuff I've come to depend on.
I'd be curious - what do u use, and why? I've been meaning to look into getting my own blog restarted, but just haven't gotten down to the question of which static site generator to use.
More than $300,000 was raised on Kickstarter for Ghost, so after seeing this public release of Ghost I was really surprised. It is so simple, I could have paid a developer $500 to make it with more features.
The Ghost admin panel doesn't allow editing themes, the post doesn't have buttons that allow you to quickly format posts, there are no SEO options/plugins, there is no theme editor that allows editing of themes, no sidebars, no multi-user creation, no e-mail to post, etc. Too many features are missing and this is very simple. WordPress is better, there just is no debate on this right now.
This is the first public release, to get feedback. They already stated (on their own blog) that an improvied admin panel, themes, plugins, etc. will come but it will take some time.
Also, we are talking ~37k lines of code, not exactly something you can write in a week or two for $500.
In the real world, people need compatibility more than they need whatever cleanup you're able to do by breaking compatibility. Heck, in many cases you can get both by doing your rewrite but leaving a compatibility layer on top that gives you the compatibility that you need.
I'm so sick of trendy "modern" frameworks like Rails that break compatibility every 5 minutes, and listing breaking compatibility as a major feature is a huge turnoff.
How about focusing on spending the pre-1.0 releases iterating and designing a really good API that will be amenable to backwards compatible extensions, and then sticking to that API and backwards compatible extensions to it for the forseeable future?