ASKING to the community: Is 2-WEEKS RELEASE cycle is fine or we should release LESS FREQUENTLY?

[hikalkan]

We want to get feedback from the community about the release cycle of the ABP Framework

We are releasing a minor/feature version, like 2.3.0, 2.4.0... in every two weeks for a long time. The main motivation behind this decision was to deliver the value early and keep our core team motivated and dynamic. Since we are rapidly adding new features and making enhancements, we don't want to wait the community to use these new features.

However, getting a new minor version in every 2-weeks may make the community hard to follow the new features & changes and upgrade to the new version every time (while we don't introduce important breaking changes in minor versions and abp update command handles it in most cases). We know, getting behind of the latest version doesn't feel us good :)

So, we are asking to the community to change the 2-weeks release cycle to 3 or 4 weeks or keep the 2-weeks? We want to get feedback. Even a simple "2", "3" or "4" response is pretty appreciated. Thanks a lot :)

BTW, we will also start to publish RC versions in a short time (see #4691). This will makes the stable releases more stable.

[StevenOwenNell]

I vote to keep it at 2-week intervals to keep the momentum going for now - I think we should ask this question at every major release.

[abierhaus]

I personally believe that most useful features are now implemented. New and changed features should run more stable and be better documented. I think many new features are for most of the Nice-To-Have (for example Chat).

Therefore I would like to suggest a 4 weeks rhythm. This will reduce the time needed for updates significantly, from 26 update cycles to 12 per year.

[kgamalseif]

4 weeks is good :).

[wakuflair]

4 is better

[antosubash]

4-weeks is better.

[xewn]

2 weeks

[xewn]

A release frequency of two weeks is a more appropriate pace. Users who are concerned about instability can choose multiple versions themselves before updating and upgrading.

[jimmidier]

2 weeks. Slowing down the pace doesn't change the objective fact of whether the framework needs enhancement or not, and I think there's still space left for new features and enhancement. Also I agree on reconsidering this at every major release.

[gdlcf88]

4-weeks is nice. Modules managed by open source communities are hard to be upgraded frequently.

[JadynWong]

4 weeks

[michaelsudnik]

2 weeks is nice, especially with associated release notes and blog posts, as it gives usets visibility of the potentially high impact new features being introduced and leaves it up to the users if they want to update.

However, if you think that future development will include less whiz bang features, then 4 weeks might be more appropriate.

[seanalford]

I vote for 2 weeks. Keep the momentum going! If someone prefers a 4 week cycle they can simply pull the updates every 4 weeks.

[g8ks]

2 weeks

On Thu, Jul 9, 2020 at 13:35 Sean Alford notifications@github.com wrote:

I vote for 2 weeks. Keep the momentum going! If someone prefers a 4 week cycle they can simply pull the updates every 4 weeks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/abpframework/abp/issues/4692#issuecomment-656100888, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSHB2C6OPEGU3P2S36G2NTR2W2QXANCNFSM4OVKKAMA .

[geffzhang]

2 weeks is nice ，Lean Agile

[zhchlmm]

I vote for 2 weeks.

[mifercagri]

4

[XuJin186]

2

[HiteshAnshani]

4 weeks but with more good documentation of each module if possible.

[hikalkan]

Thank you for all the responses and the great attention. Please continue to share your responses, ideas and comments. We will evaluate all :)

[buaziz]

3 weeks release an RC finalize and release stable on 4th week.

[hikalkan]

What about that (close to the response of @buaziz):

1. week: -
2. week: 3.1.0 RC
3. week - (rc2, rc3... if necessary)
4. week: 3.1.0 Final
5. week - (3.1.1, 3.1.2... if necessary)
6. week: 3.2.0 RC
7. week - (rc2, rc3... if necessary)
8. week: 3.2.0 Final ...

We release a stable version in every 4-weeks, but we release the RC in the middle of this period. So;

• We have time (2-weeks) to get feedback, test and stabilize the version. In this time we continue to develop features for the next version, as always.
• We have time to complete the documentation for the new features before the stable version.
• Module developers have time to adapt to the new version. We don't add any code to the RC except bugfix. When we release the stable version, they can immediately update and release their modules.

For anyone only interest in the stable versions, they can update once in 4-weeks.

[hikalkan]

thanks to @cotur to draw a visual table for my comment :)

[gdeswardt]

First of all awesome job everyone involved for creating such a good framework. Love it.

Documentation, more samples and tutorials are key to drive a deeper adoption and widen the community support at this point.

My vote is to release smaller changes more often!

[ninomartini]

I want to say I appreciate your team's hard work. As for me, it does not matter if it is 2 or 4 weeks as long as new features introduced are documented.

[shivubasavaiah]

Great job so far. Keep up the momentum with 2 weeks cycle.

[AppBotTech]

3 weeks sounds fine. Hope to see Blazor UI soon. Thanks for all your hard work.

[FrancoisKr]

2 weeks, thanks guys!

[SpiraMira]

@hikalkan - I think your proposed re-baseline to 4 weeks with RC releases is just fine. In my opinion, revisiting the release schedule is a good remedy as long as it addresses the following:

• better unit testing and integration testing to reduce bugs (out of the box)
• better abp suite testing and integration
• better abp suite angular support (so it keeps up with the mvc side of the house - razor or blazor UI)
• more abp suite crud generator features (including n-to-1 and n-to-n)
• documentation that's always in sync with the releases

as long as this all improves stability ...

Thanks guys

[dicksonkimeu]

2 Weeks

[lanpin]

2

[Qboat]

2 weeks

[hikalkan]

Thank you all for your great interest in this topic.

I see that 2 and 4 are almost equals.

We will try 4-weeks development/release cycle for 3.x versions to see if it is effective for the development and stability. If it doesn't work as we expect, we can always change in the future.

In addition to the comments I've done before, this new stable/rc release cycle may have some other additional benefits. For example (to be honest), we see that completing a medium to large feature takes more than 2 weeks (more than one milestone currently). It sometimes leads us to select smaller features to add to the milestone. 4-weeks development cycle may motive us to work on bigger features and we don't worry to not add a significant feature for the next release.

We see.. I hope this change brings more complete, stable and documented features :)

Thank you all for commenting on this issue.

[zhishile]

2 weeks