nopCommerce 4.30 is released
- 90
- 875
- 28/12/2011
- United States
So there's a minor release containing a bug fix and the version is still 4.30 instead if 4.31? The point of version numbers is so that:
a. releases can be identified.
b. determine wether a release is earlier or later than another release
You guys at NopCommerce need better release management, or it will runaway on you and turn into a living nightmare. In addition, minor updates should be released as small, change sets that can be easily applied to a production server to minimize downtime.
I suggest learning and incorporating best practices for release management. NopCommerce has been very successful with a growing core developer team. I suggest creating a release management strategy now before going forward.
a. releases can be identified.
b. determine wether a release is earlier or later than another release
You guys at NopCommerce need better release management, or it will runaway on you and turn into a living nightmare. In addition, minor updates should be released as small, change sets that can be easily applied to a production server to minimize downtime.
I suggest learning and incorporating best practices for release management. NopCommerce has been very successful with a growing core developer team. I suggest creating a release management strategy now before going forward.
MVP
Socio de Solución de Oro
Desarrollador Certificado
- 556
- 6852
- 7/11/2017
- India
ralphberger wrote:
+1 for his idea. I think we should follow this for nopCommerce.
Best regards,
Atul Rungta
So there's a minor release containing a bug fix and the version is still 4.30 instead if 4.31? The point of version numbers is so that:
a. releases can be identified.
b. determine wether a release is earlier or later than another release
You guys at NopCommerce need better release management, or it will runaway on you and turn into a living nightmare. In addition, minor updates should be released as small, change sets that can be easily applied to a production server to minimize downtime.
I suggest learning and incorporating best practices for release management. NopCommerce has been very successful with a growing core developer team. I suggest creating a release management strategy now before going forward.
a. releases can be identified.
b. determine wether a release is earlier or later than another release
You guys at NopCommerce need better release management, or it will runaway on you and turn into a living nightmare. In addition, minor updates should be released as small, change sets that can be easily applied to a production server to minimize downtime.
I suggest learning and incorporating best practices for release management. NopCommerce has been very successful with a growing core developer team. I suggest creating a release management strategy now before going forward.
+1 for his idea. I think we should follow this for nopCommerce.
Best regards,
Atul Rungta
- 117
- 1006
- 6/9/2014
- Australia
ralphberger wrote:
Your post makes too much sense!
I've personally had reservations about the process of upgrading nopCommerce and my concerns grew after I've written only one plugin last year.
There is a degree of tight coupling using dependency injection of the core service into the plugins. For the plugin developers, the current DI design makes its easier to access core services, good for application performance but it has created a technical debt. It makes future version of the nopCommerce core difficult to release as the plugins must be align to the 'same version' of nop.
Rather than DI for plugins, maybe its best for plugins to call an API (no official implementation) to remove this hard coupling.
I'm sure its easier said than done but this is just my opinion...
I suggest learning and incorporating best practices for release management. NopCommerce has been very successful with a growing core developer team. I suggest creating a release management strategy now before going forward.
Your post makes too much sense!
I've personally had reservations about the process of upgrading nopCommerce and my concerns grew after I've written only one plugin last year.
There is a degree of tight coupling using dependency injection of the core service into the plugins. For the plugin developers, the current DI design makes its easier to access core services, good for application performance but it has created a technical debt. It makes future version of the nopCommerce core difficult to release as the plugins must be align to the 'same version' of nop.
Rather than DI for plugins, maybe its best for plugins to call an API (no official implementation) to remove this hard coupling.
I'm sure its easier said than done but this is just my opinion...
- 92
- 774
- 22/9/2017
- United Arab Emirates
All the version 4.3 plugins have been updated, you can see them here sooner than everyone & enjoy!
https://shop.resanehlab.com/
https://shop.resanehlab.com/
- 1
- 5
- 1/9/2019
- Australia
I have used your app before and love your product.
I am developing with ASP.NET Blazor WebAssembly and have a tool that
creates code against DB Tables.
Please check website:- https://blazatech.com/
I would love to work on a conversion project of your app.
Blazor webAssembly is the future.
Hope you can use me in some form.
Regards
Kalvin (Australia)
I am developing with ASP.NET Blazor WebAssembly and have a tool that
creates code against DB Tables.
Please check website:- https://blazatech.com/
I would love to work on a conversion project of your app.
Blazor webAssembly is the future.
Hope you can use me in some form.
Regards
Kalvin (Australia)