When a new version of nopCommerce is released plugin (and theme) vendors need to upgrade their plugins. (Enterprise) customers need to upgrade their sites. This requires development capacity. Especially in larger environments this needs to be planned for. Having a fixed release cycle allows plugin vendors and enterprise customers to plan ahead.
If you plan for two releases a year the schedule could be as followed:
Feb 14: Code freeze
March 1st: Release candidate
April 1st: Stable version
August 16: Code freeze
September 1st: Release candidate
October 1st: Stable version
All the functionality that is completed at the time of code freeze will be included in the version. Between code freeze and release only bug fixing and stabilizing will be done. New functionalities that are not completed will be postponed until the next release.
Basically this means that end users and vendors know exactly when a new version will be released. The contents of the release will be finalized at the time of code freeze. (about 6 weeks before the release)
This allows plugin vendors and end customers to plan their capacity for upgrading in advance.
Off course you can still release intermediate "patch versions" for critical security issues and bug fixes. Or customer specific releases for your enterprise support customers.
From past experience I know that having a fixed release cycle really helps (enterprise) organizations in maintaining and planning operations.
Switching to a time based release cycle
MVP
Bronze Solution Partner
- 2898
- 23165
- 1/8/2010
- United States
I can certainly see an advantage in a fixed-release cycle for vendors / developers and I agree with you @Nopaholics. You have raised a really good point.
With a rolling release (what nopCommerce is been following so far), some bugs may appear in a production version (which are usually corrected in the next release OR via a patch version). On the other hand, major improvements / features (that requires a lot of development work from nopCommerce team) may take months or even year to appear in a fixed-release if it is not ready by the time of the release (fixed-date). I can see the arguments for both sides but I agree with you that fixed-release cycle will help developers & vendors for upgrading their products. I guess, it also comes down to what users of nopCommerce prefer (in terms of release cycle).
With a rolling release (what nopCommerce is been following so far), some bugs may appear in a production version (which are usually corrected in the next release OR via a patch version). On the other hand, major improvements / features (that requires a lot of development work from nopCommerce team) may take months or even year to appear in a fixed-release if it is not ready by the time of the release (fixed-date). I can see the arguments for both sides but I agree with you that fixed-release cycle will help developers & vendors for upgrading their products. I guess, it also comes down to what users of nopCommerce prefer (in terms of release cycle).
MVP
- 11324
- 100972
- 5/22/2011
- United States
It seems like a good idea, but consider that it means six weeks less development time for the core team to do new features. The question then becomes whether new features added/improved in last six weeks really have any impact on a 3rd party (plugin) developer. Andrei has already indicated that releases would probably be twice a year, and so far it seems that year to year they occur at about the same time/month.
- 48
- 810
- 3/10/2015
- Netherlands
New York wrote:
The core team doesn't loose 6 weeks of development. In fact they can start developing on the next release six months earlier!
Stabilizing needs to be done anyway before releasing a next version. So a code freeze before releasing a new version cannot be avoided. The only difference is that using a fixed release cycles the code freeze, stabilizing and release moments are fixed.
It seems like a good idea, but consider that it means six weeks less development time for the core team to do new features.
The core team doesn't loose 6 weeks of development. In fact they can start developing on the next release six months earlier!
Stabilizing needs to be done anyway before releasing a next version. So a code freeze before releasing a new version cannot be avoided. The only difference is that using a fixed release cycles the code freeze, stabilizing and release moments are fixed.
- 48
- 810
- 3/10/2015
- Netherlands
New York wrote:
I have experienced a transition from "content based" to "time based" releases more than once. And this concern is being raised every time. (In fact I had the same concern the first time)
But if you look at it this will always be the case. With any release there will always be features that didn't make it. And there will always be customers who would have hoped to see those features make it.
And clearly specifying a freeze period makes it look like development time for a release is lost. But a freeze followed by a stabilizing period will need to be there for any release. Regardless whether it's fixed in time or not.
In my experience for companies who have to implement the releases (whether it's store owners or plugin developers) the benefit of having a fixed release schedule that they can plan around far outways the "risk" of features not making it into the release. (All the companies I experienced making the transition, as well as their clients, are really positive about it afterwards)
...can start developing on the next release six months earlier...
Yes, and then the store owners have to wait six months to get the features that they were hoping for (as per the proposed workitems).
Yes, and then the store owners have to wait six months to get the features that they were hoping for (as per the proposed workitems).
I have experienced a transition from "content based" to "time based" releases more than once. And this concern is being raised every time. (In fact I had the same concern the first time)
But if you look at it this will always be the case. With any release there will always be features that didn't make it. And there will always be customers who would have hoped to see those features make it.
And clearly specifying a freeze period makes it look like development time for a release is lost. But a freeze followed by a stabilizing period will need to be there for any release. Regardless whether it's fixed in time or not.
In my experience for companies who have to implement the releases (whether it's store owners or plugin developers) the benefit of having a fixed release schedule that they can plan around far outways the "risk" of features not making it into the release. (All the companies I experienced making the transition, as well as their clients, are really positive about it afterwards)