More in this section
Categories
Bloggers
Blogs RSS feed

Unexpected issues with upgrades – Sitefinity 3.6 official release postponed several days

by Ivan Osmak
I am very sorry to inform you that during the testing this week we have ran into some unexpected complications when it comes to upgrading older versions of Sitefinity to the new Sitefinity 3.6. While we have been determined to release the official version this week and everything was running on schedule, the last minute issues have forced us to move the date yet again.

 

We have been discussing the possibility to release with the upgrade problem as a known issue, but we have decided that the issue is too critical and would cause many problems to all of you upgrading Sitefinity.

 

On the behalf of the whole team, I apologize and assure you that we are all working very hard to release the stable version with tons of new, developer orientated features, as soon as possible.

 

Thank you for your understanding.

11 comments

Leave a comment
  1. JWal Feb 06, 2009
    I can certainly relate!

    Personally, we are waiting for the new release to begin working with SiteFinity from the beginning, without any upgrade requirement.

    Would you recommend starting with the Beta release or wait for the final release?

    We're ready when you are.
  2. Shannon Dunn Feb 06, 2009
    I am in a holding pattern waiting on this release and my company's future is held in the balance. We have technology we are moving from one platform to SiteFinity that requires 3.6 to be there. We have been testing the product and were expecting to allow our content providers to hit the streets running in a week. Is it possible to get the version of the product that has the known issue since we are NOT upgrading?
  3. Chris Williams Feb 06, 2009
    I'm not with SiteFinity, but my opinion is that there's a lot to learn from an initial SF deployment, and it's always best to get started early :).

    I've been using the beta (anxiously awaiting final) and imho it's plenty stable to deploy and start roughing your CSS that you'll use in UI, youur main feature areas like blogs, forums, etc. and basically to get your feet wet.  The beta deployment should migrate to final code relatively easily.
  4. Colin Bowern Feb 06, 2009
    I'd concur - another beta drop would be nice.
  5. Ben Feb 07, 2009
    This seems to be a typical pattern with Sitefinity (I've been using SF for about 2.5 years now and during the upgrade from 2.7 to 3.0 which ended up running about 4 months behind schedule and this type of pushed release date was very common).

    I'd just like to suggest one more time that you reverse your deployment strategy and implement Dell's "Under Promise, Over Deliver" strategy.  If you think you can release 3.6 on 2/6, announce it for 2/13.  If you are ACTUALLY able to deliver it on 2/6 everyone is SUPER happy because they weren't expecting it for another week.  If you deliver on 2/11, Yay, if it's actually 2/13, well, that's what you promised, right?

    Just my $0.02

    Ben
  6. A different Ben Feb 07, 2009
    I remember the transition to 3.0 and yes that was tough. But that was a four month delay from October to January. However, I don't mind a couple of days. I like that the Sitefinity team pushes hard and keeps us informed as to exact days rather than the Beta 1, Beta 2, RC method. I think their current strategy leads to faster development. Which means more new features faster for us to wow are clients with.

    Now on our end we should be under promising and over delivering to our clients so that  a couple of days delay is not mission critical.

    That's just one developers opinion.
  7. John Peterson Feb 07, 2009
    I'd like to get a stable release not a buggy one. I regret to hear that the release will be postponed, but I believe that Sitefinitt team will manage to release in the next few days one version with less bugs and more features.

  8. Mike Feb 10, 2009
    Likewise, I would prefer to wait until you think it's ready, than deal with "known issues".

    As for the betas, I actually see no virtue in those, and don't waste my time with them. The Telerik products are essentially in constant "beta" state anyway, as each "release" is just an interim product, while bugs, requests and new features are addressed/implemented. The products are updated so fast and, so called, service-packs, issued so frequently (not trying to infer either as bad) that the entire value of public betas is highly questionable for anyone outside Telerik.
  9. Shannon Feb 10, 2009
    Mike, that is the point of Public betas. Having worked at Microsoft for years on ASP.NET I cannot tell you how important it is for Telerik to have betas and release them to the public because you need something more than dogfooding. Its how Windows 7 will be done BETTER than Windows Vista...early and often beta testing will allow them to see the flaws they might not find on their own.
  10. Mike Feb 10, 2009
    Shannon,

    I think you are possibly missing my point.

    Telerik products are quite different to Microsoft's, in that they are constantly changing, on a quarterly, monthly and (at times) weekly basis. Even the between-release ‘service packs’ will often see entirely new (and too often undocumented) features added that have not been trialled outside of Telerik.

    Hence, the products are effectively ALWAYS in beta...  akin to the way much of Google software is in a permanent state of beta.

    I’m not saying this is a bad thing, or is an undesirable approach, just saying that this is a reality of the product and the market it meets.

    The products are already subject to constant feedback, bug-fixes, additions, changes, requests, ideas... and so I don't see the value of injecting yet another layer into that fast-changing mix, which is essentially... “code we know doesn't work yet” ...and release that a bare minimum amount of time ahead of the fixed version.

  11. Kevin Feb 10, 2009
    Are we talking a few days or a few months delay? I'm actually postponing projects because I'm waiting on the 3.6 release. I'm firm in the fact that I'm not going to produce new Modules for these projects using 3.5 and want to use the new architecture since it's going to cut my development time in half.

    Leave a comment