No ETA quite yet, but my goal is to have it done within the next few weeks.
I have been able to put a lot more time into BrowserCMS lately. My priority
so far has actually been going back, fixing existing modules for Rails 3 as
well as the performance improvements I just released today. I have a few
other odds and ends to wrap up, and then I should be back on 3.4 to wrap it
up.

Hi Patrick,

Great stuff and thanks for the updates.

We'll be looking at the upgrade you mentioned for our site
www.hovisbakery.co.uk which will really help with performance while editing
the site.

BTW, are there any solutions around being able to only cache certain areas
of a page rather than a whole page?  Or rather the opposite?

Thanks again for a great Rails CMS! =)

Niklas

On 25 January 2012 22:26, Patrick <pea...@gmail.com> wrote:

Also, have you considered reworking the homepage to be more akin to
http://refinerycms.com/?  The reason I ask is that their CTA and stats
are a very compelling aspect for getting people on board and feeling
good about it very quickly.  I think with some tweaks like that and
some marketing tweaks BCMS could really draw a lot more into it as
it's just simply the best CMS available for Rails at the moment in
terms of the feature set and your overall vision for it (being more
akin to Concrete5).

On Jan 25, 6:46 pm, Niklas Richardson <niklasrichard...@gmail.com>
wrote:

Niklas,

Thanks for the feedback on the website itself. The current design was a
very quick 'get something' up, so we are definitely open to changing it,
along with all the other improvements we are making to the project. I do
see what you mean about about Refinery's page being more heavily focused on
community stats/watchers, etc (though I'm not sure what you mean by CTA?).

Regarding computability targets, I'm about 100% sure I want 3.4.x to be
Rails 3.1.x compatible, if only to make sure we have major releases that
work with each major Rails release. Especially since much of the 3.4.x
release will be focused on being able to drop BrowserCMS into existing
apps, I would not want to force users to have to upgrade to Rails 3.2 just
to get BrowserCMS. If the difference between Rail 3.1 and 3.2 is as limited
as I think it is (nothing as impacting as Asset Pipeline or Isolated
Engines), then I will probably try to follow up with BrowserCMS 3.5.x in
quick succession that will be Rails 3.2.x compatible.

Much of my work this week is likely to be on polishing up the 3.4 for
release, and I made several pushes to master last week, so I'm feeling
pretty good about it. I'm spending a lot of time right now adding
Cucumber/Aruba tests around all the generators/Thor apps we use for
starting new projects, but baring any issues there (I know of one), I'm
really just bug squashing right now. I have also been testing out upgrading
modules to make sure they work with 3.4.x as well. For example, both the
bcms_news and bcms_fckeditor have been updated on github (master) to ensure
they work correctly.

Hopefully, this means with the 3.4.0 release, there will be minimal issues
with upgrading existing BrowserCMS projects and/or Modules, but like I
said, that's what I'm testing this week.

Awesome news Patrick.  By CTA I simply meant "Call To Action" in that they are very focused on conversion of visitors and give them a very direct call to action with numbers to back it up.  It's really not a big tweak, but I think it would be a big boon to BCMS.  I would love to see more adopters and especially experienced contributors get involved.  We could all do with the benefits from that.  

As I noted in my other message not long ago, I think the Refinery Heroku page could serve as near 1-to-1 blueprint for getting BCMS to run there, which would be another big benefit as Heroku offers folks a quick initially free solution to throw BCMS out into the wild.  I think a lot of projects who support Heroku get a big boon from this path.  As it's easy to experiment with, perhaps you could spend a couple hours just deploying the bcms demo to heroku?  I'll reply to the other message I posted with some notes in case you'd be able to do that.  It should make it a fairly minimal and straightforward task for you in that you understand things intimately.

Thanks,

-George

On Feb 21, 2012, at 3:24 PM, Patrick wrote:

Niklas,

Thanks for the feedback on the website itself. The current design was a very quick 'get something' up, so we are definitely open to changing it, along with all the other improvements we are making to the project. I do see what you mean about about Refinery's page being more heavily focused on community stats/watchers, etc (though I'm not sure what you mean by CTA?).

Regarding computability targets, I'm about 100% sure I want 3.4.x to be Rails 3.1.x compatible, if only to make sure we have major releases that work with each major Rails release. Especially since much of the 3.4.x release will be focused on being able to drop BrowserCMS into existing apps, I would not want to force users to have to upgrade to Rails 3.2 just to get BrowserCMS. If the difference between Rail 3.1 and 3.2 is as limited as I think it is (nothing as impacting as Asset Pipeline or Isolated Engines), then I will probably try to follow up with BrowserCMS 3.5.x in quick succession that will be Rails 3.2.x compatible.

Much of my work this week is likely to be on polishing up the 3.4 for release, and I made several pushes to master last week, so I'm feeling pretty good about it. I'm spending a lot of time right now adding Cucumber/Aruba tests around all the generators/Thor apps we use for starting new projects, but baring any issues there (I know of one), I'm really just bug squashing right now. I have also been testing out upgrading modules to make sure they work with 3.4.x as well. For example, both the bcms_news and bcms_fckeditor have been updated on github (master) to ensure they work correctly.

Hopefully, this means with the 3.4.0 release, there will be minimal issues with upgrading existing BrowserCMS projects and/or Modules, but like I said, that's what I'm testing this week.

--
You received this message because you are subscribed to the Google Groups "BrowserCMS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/browsercms/-/L37fGpOROCwJ.
To post to this group, send email to browsercms@googlegroups.com.
To unsubscribe from this group, send email to browsercms+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/browsercms?hl=en.