More in this section

Forums / General Discussions / Change the Sitefinity Release Schedule

Change the Sitefinity Release Schedule

5 posts, 0 answered
  1. RickC
    RickC avatar
    24 posts
    Registered:
    23 Apr 2003
    26 Mar 2012
    Link to this post

    I've been a very happy Telerik customer for many years and have built numerous sophisticated applications with Telerik Controls. I've also begun using Sitefinity as a key part of my Web strategy. The Sitefinity release dates have corresponded with the release dates of the Telerik Controls. Going forward I strongly recommend that Sitefinity to branched off to have its own release cycle.

     

    The reason for this suggestion is that Sitefinity is an full-featured Application rather than a set of Controls and as such is both complex and requires broader levels of testing and documentation.

     

    As a case in point, I had my Sitefinity 4.4 Ecommerce site all set up and running fine ready to be rolled out to customers. I decided to postpone opening it live until after 5.0 was released to be able to add the digital downloads product features and so as not to have downtime on the site during the upgrade. Unfortunately, after upgrading there have been a number of problems and bugs affecting my Ecommerce store which won't be fixed until the 5.1 service pack. I greatly appreciate the time Telerik Support have spent helping me and providing workarounds for things like Checkout User Login until 5.1 is released. Since my Ecommerce store can't wait until an unknown date of 5.1, I've opened it, bugs and all.

     

    I've spent way too much time troubleshooting problems with 5.0,  I would have been better staying with 4.4. I would be willing to be patient about new features being added didn't expect parts of the site that worked in 4.4 to stop working.

    Also, based on forum discussions, there are a number of people (myself included) who have had the upgrade process complicated by confusing documentation (for example  around Forms Authentication vs the new Claims Authentication and what the Web.config should look like). Part of that issue is that the Documentation is not adequately written in places and there some earlier Sitefinity documentation was simply incorrect (for example incorrect Authorize.net Payment Gateway settings which were quickly corrected after I brought it to the attention of Telerik Support).

     

    All of this points to a need for greater testing of the product before release and more time to create proper documentation. The type of documentation required for a Product like Sitefinity and all of it's interlocking modules is more more detailed than the documentation for how to use a RadGrid. Telerik needs to approach the Sitefinity documentation from a very different technical writing style.

    Locking the Sitefinity release date to the same release timeline with the rest of the Telerik Controls can mean releasing a less than optimal product. I for one would rather wait longer and receive a stable upgrade with clear instructions on installation and use than spend time addressing issues that break my existing fully operational site. Stability has to be job one for any upgrade.

     

    I hope that Telerik management will consider this moving forward as a way to best support Sitefinity customers.

     

    Rick

  2. Jeff Clark
    Jeff Clark avatar
    8 posts
    Registered:
    04 Feb 2010
    26 Mar 2012
    Link to this post
    I completely agree with all of the sentiments above. This gets my vote.
  3. SVA Webmaster
    SVA Webmaster avatar
    85 posts
    Registered:
    18 Jul 2007
    26 Mar 2012
    Link to this post
    You have my vote. I've posted a similar thread in here about bug-fix only releases (service pack) as well, so we aren't forced to upgrade to "new functionality releases" in order to get our bug fixes. 
  4. MB
    MB avatar
    302 posts
    Registered:
    09 Jan 2005
    26 Mar 2012
    Link to this post
    I actually have no issue with the release schedule of new versions that provide new functionality - there are 3 'Q' upgrades each year, and that certainly doesn't seem excessive to me.

    However, I do have an issue with the fact that bug-fixes are tied to new versions only, forcing you to take on new bugs to fix old bugs... which is *REALLY* frustrating when those old bugs are not fixed, and you now have a bunch of new ones to deal with.

    I appreciate Telerik's dilemma in this need to include competitive product features, and I don't know what the solution should be, but I have this fuzzy notion that each version should be maintained through at least one (or more?) upgrades - receiving only the relevant bug-fixes that were applied in the upgrade.

    e.g.  When 5.1 is released, 5.0.1 is also released... so people can choose to take on the new version with its new features, or just patch their current version.
  5. Georgi
    Georgi avatar
    3583 posts
    Registered:
    28 Oct 2016
    29 Mar 2012
    Link to this post
    Hello guys,

    Thank you everyone, for describing what does and what does not work for you. This kind of feedback is extremely valuable and of course we take it seriously.

    We've been thinking for this for some time, but in order to provide fixes separately with the new releases, we'll need to do some logistic and environment changes that we currently have within the team. The implications of such changes would be more versions to support from our side, more upgrade scenarios and of course more time for testing. Yet we understand that this is probably the way to go, since indeed, most of the times you just need fixes for the stuff that's already deployed rather than system with new features.

    We hope that over the course of this year we'll come up with a solution to this inconvenience.

    Just a note on the documentation - it's true we've spent the last year with a priority on new features, and the documentation suffered from this. As you can see from our Roadmap, we are now putting more efforts in polishing the details, producing better documentation and writing more real world how-tos. We've made the step forward to actively collect feedback on every single article that we have across the guides (screenshot attached). We believe that with your feedback in mind we'll improve the documentation a lot. So keep this feedback coming :)

    Once again, thanks for sharing your thoughts. We appreciate it.

    All the best,
    Georgi
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
5 posts, 0 answered