Too many updates, too frequently maybe?

Hello,

Can I just get a reality check? Is it just me or are there others out there that also feel there seems to be updates just way too frequently?  It's great that we now recently have an upgrade guide but we have around 10 websites and upgrading them is very tedious especially if they become out of sync'.  Updates aren't even accumulative; we have to "downgrade in order to upgrade" each time!  Don't get me started on Sitefinity Thunder upgrade prompts (they're like STDs that you can't get rid of).


Could upgrades be bigger, less less disruptive, and more friendly?

How about also making that "upgrade" button do the work or renaming it to "Upgrade to 99%" because it seems a lot of things needs to be added to the web.config later on.   In addition, maybe I can't complain about this so much now that there's an upgrade map thing, but surely the Project manager should check if it's safe to upgrade a project? I,e,  it prevents users from upgrading from 4.0 to 5.0, or a 5.0 to 5.4 accidentally.  And auto backup would be the icing on the caking.

I'm sorry but I would disagree with you.
I am comfortable with the releases and updates that are produced.
And the bigger the release, the bigger the chance of something not working in my opinion. So I wouldn't like to see this.

I also have about 10 sites to update but for me the physical process of updating from dev to production is about 30 minutes. (this only includes basic testing of each custom component, which some people will won't agree with)
I put a lot of emphasis on how my projects are source controlled, upgraded and deployed and have a very firm upgrade process.
My view of software is that there is only one guarantee. And that is it will change.

I don't disagree that some sites will be a lot harder than to upgrade than others.
But remember you don't have to upgrade every release and SP. You can do each major release or every second release if it suits. (the release upgrade supports one release back I believe)

I also need to disagree with the poster

  We're still missing a lot in the CMS (polish as well as bug fixes), until we're at a point where I never encounter a bug so we're just adding features, we need these updates and service packs.  Even 2-3 months is a long wait. When you compare it to turd software like community server which have very few (but larger) updates, it's much much more cumbersome...because so much is changing.  Like this release...html5 upload work?  library hierarchy break anything?, events still there?...check, works, great, on to the next.

  I'm not sure where you have to downgrade to upgrade comes from...perhaps you've been given some bad info there...it's forward only.

  My upgrade process is similar to darrin...do 1-2 get comfortable then crank out the rest, rarely have any issues...actually until recently I just kept overwriting the bin\clientbin\Sitefinity folders, didn't even know there was webconfig updates...and everything was fine (of course I'm doing them now just in case).  Regardless the webconfig should be replaceable if at all possible.  You should be storing config elements and app settings in the sitefinity config to (again) make webconfig updates trivial.

Thank you both for your input, it helps me understand how other devs' work. I am guessing it's just my circumstance.

I think my team problem (and what I am referring to when I "downgrade to upgrade") is that we cannot batch upgrade all the sites hence we have sites on different versions and so we have to install different versions of SF at different times for the right upgrade.  We do require time to test upgrades (sometimes weeks) because we need to see how it performs and it is a lot to do with risk/fear as to what bugs / set backs the next one may bring (we've seen lots of hiccups from 4.0).  So by the time we are ready to upgrade our next website, it's likely there's another release.  Referring to Darrin's comment on lots of mini-releases -  would it not require more time and work for each release?  (Excuse the over simplified version how things work), would Sitefinity not need to prepare, document and provide on-going support  for each minor/major release? Devs would need to prep (RTFM), backup, test, deploy, (maybe rollback), do a little praying; all contributing to frequent downtime - it all adds up.  In addition, the more releases seems to be a sign that 1) there's a lot of bugs to be patched (not good for marketing) and  2) it's more room for error.  I  just think that  cumulative updates are needed and should be an option -  I'm sure(!) there is a demand for it (?)

Dear Richard

I am split on this. Lots of the new features are not of any use for me since I mostly have SBE and SE running for my clints. And yes updates take time and work.

But on every release there is one or two features (or bug fixes) I am really longing for. Like hiarchial libraries in 6.0. So I would not be happy with less updates. But I do usually hold back 5-6 versions and then start updating a whole bunch of sites so I am kind of in the update mood/mode.

Markus

From my perspective, it's not the number of updates that causes me grief, it's the incremental upgrade requirement.  I try putting off the upgrades until there's a release that contains a specific bug fix or feature that's relevant to my site.  The problem though is that this usually means I'm several releases or more behind. 

Such is the case with my current upgrade from 5.1->6.0.  In order to do the upgrade, I need to perform 3 seperate upgrades.  This is time consuming in the best of cases when all of the upgrades go well.  Unfortunately, my personal experience is that they never do.  It could be something I'm doing wrong, or something specific about the modules we've created but I can't beleive that the upgrade process is error free for most users.