Isn't it time for more than just incremental upgrades

In my old Ecommerce website there we’re always upgrade from earlier versions to the newest. You didn’t have to go through upgrading all the in between ones.



Seeing that 2.0.13 and 2.0.14 are less than perfect isn’t it time upgrades were made available from earlier versions ie 2.0.12 to to newer ones like 2.0.15 when it comes out.

Ooops, sorry, my bad

[SIZE=“2”][COLOR=“DarkOrchid”]I wouldn’t care how my increments we went through as long as they went smoothly. Right now I have a site that is practically broken due to .13, and a larger site that I have NO intentions of imploding until things get cleared up. I had to buy service points so CS-Cart could go in and fix things sigh. This is obviously going to be a pattern…[/COLOR][/SIZE]

You don’t have to do every single upgrade when it is released. I am still on 2.0.12 and when I am ready to upgrade, I will go up to 2.0.15 or whatever that version may be. As long as the version I am on is working well I see no reason to risk upgrading and running into issues that will hurt my sales. I was on 2.0.7 for months and upgraded to 2.0.12, for instance.



DawnG - When you do decide to upgrade, make a copy of your site and db and run the upgrade on it. If all goes well, then you can switch to the new version. If you don’t do it that way, the least you can do is back up all your files and database so you can switch back if you don’t like it. Or just wait and then pay someone to do it for you when there is an upgrade that adds some features or fixes you need.

[quote name=‘ogia’]You don’t have to do every single upgrade when it is released. I am still on 2.0.12 and when I am ready to upgrade, I will go up to 2.0.15 or whatever that version may be. As long as the version I am on is working well I see no reason to risk upgrading and running into issues that will hurt my sales. I was on 2.0.7 for months and upgraded to 2.0.12, for instance. [/QUOTE]



But when you do hear of a stable release that you do want you will still have to do each incremental (or that is what I’ve gathered from reading posts on her) upgrade. I’m sticking with 2.0.12 as 13 and 14 seem to have issues. but if i want 2.0.15 i will have to upgrade using these faulty releases. Surely if they just did a upgrade xxx to 2.0.15 we wouldn’t be injecting our sites with bugs. May be I’ve the whole thing wrong, may be it does just upgrade in one step but i got the impression it didn’t.

I use the web upgrade facility to do my upgrading.

To use myself as an example… I started with 2.0.7. When I upgraded to 2.0.12 I proceeded through each step, but bugs that may have existed in 2.0.8, 2.0.9, 2.0.10, 2.0.11 never affected me. My store was only live with 2.0.7 and 2.0.12.



When there is a release that has new features or bug fixes that I NEED, I will upgrade again. It does not matter what was released between 2.0.12 and then. You’ll see those versions when you are going through your upgrade, but where you ultimately end up is the only version you need to worry about.



This isn’t anything new… I go through a similar process every time I want to upgrade my vBulletin forum. I start with the version the forum is running and work my way up to the most recent version released by vBulletin.

[quote name=‘mrfoameruk’]But when you do hear of a stable release that you do want you will still have to do each incremental (or that is what I’ve gathered from reading posts on her) upgrade. I’m sticking with 2.0.12 as 13 and 14 seem to have issues. but if i want 2.0.15 i will have to upgrade using these faulty releases. Surely if they just did a upgrade xxx to 2.0.15 we wouldn’t be injecting our sites with bugs. May be I’ve the whole thing wrong, may be it does just upgrade in one step but i got the impression it didn’t.

[/QUOTE]

You are correct that you will need to step through the upgrades but each successive upgrade will repair any problems from previous updates that have been identified and fixed.



There really is nothing magical about doing a combined update and it might be more problematic: they still need to package all the updates from the previous releases. Often, the problems that arise are the result of something missed in an update (a file change, a DB change); if they can miss something across a single update, what do you think the chances are that they might miss something in a combined update across 3 or 4 versions?



The one real advantage is that it saves time.



Bob

It would be nice if you could choose from types of upgrades. Maybe have a 2.0.15 upgrade that just upgrades everything but the template. Maybe one that has just the template upgrade. This way it could allow the user to choose what upgrade they want without causing issues with design of functionality. I’m not a coder/designer so this might be impossible but if some way we could have options on the upgrade would be great.



Stu

[quote name=‘derbytown502’]It would be nice if you could choose from types of upgrades. Maybe have a 2.0.15 upgrade that just upgrades everything but the template. Maybe one that has just the template upgrade. This way it could allow the user to choose what upgrade they want without causing issues with design of functionality. I’m not a coder/designer so this might be impossible but if some way we could have options on the upgrade would be great.



Stu[/QUOTE]



This could be a nightmare for the developers. Once you start allowing updates of just sections of the code then you find yourself having to manage and support variations of the product rather than just the newest release. Not only that but many of the core php and database changes/additions require some addition or modification to the template so the new functionality can work properly.

Thanks for the explanation adodric…thought maybe a reason why this couldn’t happen. Just wishful thinking. I guess anything worth having is worth investing the time and work to accomplish your goals.



Stu

The upgrade process/tools is one of the better areas of the admin of cs-cart. It is logical and step-oriented so there’s no confusion about what’s happening. The “revert” functionality even seens to be working since about 2.0.10 or so. Only wish there was a way to preserve data not related to a column change in the db. I.e. customer upgrades from 2.0.12 to 2.0.14. After a day or two they discover a problem that they just can’t live with so they revert. Unfortunately, if there was any change to the orders table (like changing/adding a column) the orders table will be restored and all their orders over the past couple of days disappear. Be nice if each uc.sql had a sister file called uc-revert.sql that would simply back out the alter tables versus save/restore of the whole table.



The other area I’d like to see improved is the “mark as resolved”. seems like on the “diff” page one should be able to “return and mark resolved” or “mark resolved and next” or just “return” (but none of those exist so you need to use the back button). When the list of conflicts is greater than the pagenation size, it’s a pain to have to keep scrolling to the right release, then scroll within the list of conflicts, click “mark as resolved” and have the page redraw and have to start scrolling all over again!



You can’t delete the prior releases until you’re convinced that the current one is acceptable…