On 21 May 2020 I downloaded nopcommerce 4.30 with source code.
Today, on 8 June 2020 I re-downloaded nopcommerce 4.30 with source code.
I compared the source of this version downloaded on 8 June with the version downloaded on 21 May and found that changes had been made to the following files:
Nop.Core/Domain/Common/CommonSettings.cs
Nop.Services/Common/NopCommonDefault.cs
These files had been changed for the addition of a RestartTimeout property.
I also found soon after the release of nopcommerce 4.20 that (when I downloaded again later) that a number of changes had again been made to the released source code.
So (from my understanding of release numbers on other projects) I now have the following questions:
1. Why isn't the version number updated to reflect that a change has been made to the released source code?
For example, why is it not now 4.31 or 4.30.1?
2. How do users know that changes have been made to the released source code if the numbers do not change?
Am I missing something here? If I can't see that a version number has changed, should I keep coming back to the site, downloading version 4.30 and running a source code comparison to check if changes have been made to the release?
Why are changes made to the released source code without changing the version number?
MVP
- 11324
- 100972
- 5/22/2011
- United States
I can't speak to the decision as to not upgrading the version, but the changes were mentioned here
https://www.nopcommerce.com/en/boards/topic/81817/nopcommerce-430-is-released/page/4#265364, and it was said "its version is still 4.30".
https://www.nopcommerce.com/en/boards/topic/81817/nopcommerce-430-is-released/page/4#265364, and it was said "its version is still 4.30".
MVP
Certified Developer
- 3944
- 35207
- 2/8/2010
- Australia
What about introduce a build and/or revision number Major.Minor.Build.Revision
Search for plugins look at SupportedVersions which is only the Major.Minor part which need to align with the plugin. Then Both the main core and plugins can have multiple builds/revisions that can independently be updated e.g.
Main Core might go 4.3.1 to 4.3.2 to 4.3.2.1 to 4.3.3 etc
Plugin might be 4.3.1, 4.3.2
But because Major.Minor are the same the plugins are still found and it all works
Search for plugins look at SupportedVersions which is only the Major.Minor part which need to align with the plugin. Then Both the main core and plugins can have multiple builds/revisions that can independently be updated e.g.
Main Core might go 4.3.1 to 4.3.2 to 4.3.2.1 to 4.3.3 etc
Plugin might be 4.3.1, 4.3.2
But because Major.Minor are the same the plugins are still found and it all works
- 105
- 1036
- 5/25/2013
- United Kingdom
a.m. wrote:
My concern is that users may not know that a new release has been made. It is not clear to me how this information is supposed to be communicated to current users of the software so that they may choose whether to upgrade.
As user 'New York' mentioned above, the latest bug in 4.30 was fixed in an update which was communicated via a forum post (not sure if it was communicated elsewhere) but unfortunately I missed this. It was only by chance that I ran a comparison and noticed that changes had been made.
From the way that most software versions work I would potentially expect a process similar to the following:
1. Nopcommerce 4.30.0 released from git release branch and made available to download via the nopcommerce website.
2. Critical bug found and fixed in the release branch. This bug is also merged into the development branch for the future 4.40.0 release.
3. Nopcommerce 4.30.1 released from git release branch containing single bug fix.
4. When users login to nopcommerce administration they would be notified that a new version is available for download.
During the current development cycle, steps 2-4 would then be repeated each time a new critical bug is released (hopefully not too often) with the build version number incremented each time (e.g. 4.30.2, 4.30.3, etc).
5. Eventually, the next version of nopcommerce would be ready and 4.40.0 would be released.
6. When users login to nopcommerce administration they would be notified that a new version is available for download.
This (or a similar) process would increase visibility to newly released versions by:
- Allowing users to see that the version number has been incremented.
- By informing them in the administration site of their store.
Yidna wrote:
I haven't investigated what would be involved but it seems like a valid suggestion. Someone had down-voted your comment but unfortunately did not leave a comment to explain why.
In we change the version number, then all third-party plugins just stop working. "SupportedVersions" property in the plugin.json files would be different
My concern is that users may not know that a new release has been made. It is not clear to me how this information is supposed to be communicated to current users of the software so that they may choose whether to upgrade.
As user 'New York' mentioned above, the latest bug in 4.30 was fixed in an update which was communicated via a forum post (not sure if it was communicated elsewhere) but unfortunately I missed this. It was only by chance that I ran a comparison and noticed that changes had been made.
From the way that most software versions work I would potentially expect a process similar to the following:
1. Nopcommerce 4.30.0 released from git release branch and made available to download via the nopcommerce website.
2. Critical bug found and fixed in the release branch. This bug is also merged into the development branch for the future 4.40.0 release.
3. Nopcommerce 4.30.1 released from git release branch containing single bug fix.
4. When users login to nopcommerce administration they would be notified that a new version is available for download.
During the current development cycle, steps 2-4 would then be repeated each time a new critical bug is released (hopefully not too often) with the build version number incremented each time (e.g. 4.30.2, 4.30.3, etc).
5. Eventually, the next version of nopcommerce would be ready and 4.40.0 would be released.
6. When users login to nopcommerce administration they would be notified that a new version is available for download.
This (or a similar) process would increase visibility to newly released versions by:
- Allowing users to see that the version number has been incremented.
- By informing them in the administration site of their store.
Yidna wrote:
What about introduce a build and/or revision number Major.Minor.Build.Revision
Search for plugins look at SupportedVersions which is only the Major.Minor part which need to align with the plugin. Then Both the main core and plugins can have multiple builds/revisions that can independently be updated e.g.
Main Core might go 4.3.1 to 4.3.2 to 4.3.2.1 to 4.3.3 etc
Plugin might be 4.3.1, 4.3.2
But because Major.Minor are the same the plugins are still found and it all works
Search for plugins look at SupportedVersions which is only the Major.Minor part which need to align with the plugin. Then Both the main core and plugins can have multiple builds/revisions that can independently be updated e.g.
Main Core might go 4.3.1 to 4.3.2 to 4.3.2.1 to 4.3.3 etc
Plugin might be 4.3.1, 4.3.2
But because Major.Minor are the same the plugins are still found and it all works
I haven't investigated what would be involved but it seems like a valid suggestion. Someone had down-voted your comment but unfortunately did not leave a comment to explain why.