Better Upgrade Strategy

Let me start by saying: you guys do a great job! Great quality app and code! But one area where i see a lot of room for improvement is in the upgrades.

I think that there should be 3 types of downloads: Full Source Code, Full Installation (No Source Code), and Upgrade Source Code. Where the first two are just like you have today and the last option is only the source code that changed from the previous version. That way if people modified the current source code they know which file has changed and can more easily deal with merging their changes with the base code.

Thanks for the hard work.

Thanks

Hi,

Yes, I think it could be a good thing to get only modified/added files.
When 1.20 new version released, it was not easy to remember in which files i made changes :)

I agree,

I'm in the middle of coding new stuff into the 1.11 release and now I don't know which parts have changed. I have to see and then copy my code to the new release to keep it compatible...

Its not that i'm  not happy with a new release. It is just very handy for developers to know what sources have been altered ;)

Ranmonster wrote:

We will try to give more detailed release documentation. However, even with detailed documentation it is very difficult to cater for everyone's changes if they do not document them themselves.

When I implement custom changes to nopCommerce for clients I tend to create a directory in the root of the site for all changed modules as well as documenting any changes to code I may have made. So for example, rather than modifying the standard ProductBox1.ascx control, create Client/Modules/CustomProductBox1.ascx and then use this.

This way when a new version is released, you simply need to copy over your "custom" directory and apply any custom changes to the code.

Maybe we have to think about developer rules for NC. If anybody does his own 'thing' it ends in chaos.

My suggestion:

1) Make a directory where you put inside the changes on files you have made based on directory structure of NC.
2) If little changes are made to a *.ascx or *.cs (module) make a document with explanation of code altered, for example a doc with code alteration changes:

Page module:
/administration/Modules/ProductDetails.ascx

Change Code line 17:

<div class="options">
        <asp:Button ID="SaveButton" runat="server" CssClass="adminButtonBlue" Text="Save"
            OnClick="SaveButton_Click" ToolTip="Save product" />
        <asp:Button ID="DeleteButton" runat="server" CssClass="adminButtonBlue" Text="Delete"
            OnClick="DeleteButton_Click" CausesValidation="false" ToolTip="Delete product" />
    </div>

TO:

    <div class="options">
        <asp:Button ID="SaveButton" runat="server" CssClass="adminButtonBlue" Text="Save"
            OnClick="SaveButton_Click" ToolTip="Save product" />
        <asp:Button ID="DeleteButton" runat="server" CssClass="adminButtonBlue" Text="Delete"
            OnClick="DeleteButton_Click" CausesValidation="false" ToolTip="Delete product" />
<asp:Button ID="GoBackButton" runat="server" CssClass="adminButtonBlue" Text="Go Back"
            OnClick="GoBack_Click" CausesValidation="false" ToolTip="Go Back" />
    </div>

3) If there is a lot of code changed to document place page and code behind like noted in (1) and explanation  how to
/administration/Modules/ProductDetails_001.ascx
/administration/Modules/ProductDetails_001.cs


4) Put a readme.txt in the root of (1) with why you have changed the code or for what purpose the code is changes/enhanced.

Good suggestions.

How about the use of inheritance, partial classes or just like DotNetNuke does: module creation and installation.

I also want to suggest for the menu to be built from the DB so it can survive upgrades. I modifed xml to include a new page i built and had to merge the new changes in. If this were to live in the DB we would avoid yet another file to be merged.

also winmerge helps too.