I've created this issue since there is no issue in github yet, and I feel that GitHub is a better place to discuss than the forum (since 100% of contributing developers / bug reporters must use GitHub, which is not the case for the forum).
http://www.yiiframework.com/forum/index.php/topic/57781-yii2-release-schedule/
I'd love to see a timed release schedule, for example monthly releases.
Currently releases with bug fixes get blocked due to inactive PRs that have a milestone attached.
The milestone label should be an indicator but in my opinion a small enhancement should never block a release.
One option would be to have a label for blocking / non-blocking. Another option would be to interpret milestone labels as desirables but not required. As long as the tests succeed and no regressions have been identified it does not make sense to delay releases.
(Side note: when looking at labels, there is a typo in severty:security)
Theoretically this could even lead to 100% automated montlhly releases from the master branch.
Forgive me if I'm missing something, I'm not sure of the amount of work it requires to do a release, which of course could make such a release schedule a big burden.
SamMousa
All 10 comments
@samdark In the forum you say:
- Yes, something like that is planned i.e. releasing when there are more than X issues addressed. Still thinking about the best criteria for it because releasing too often is bad as well.
What is the downside of releasing often that you are referring to?
SamMousa
on 14 Mar 2017
milestone labels as desirables but not required
They are desirables.
samdark
on 14 Mar 2017
(Side note: when looking at labels, there is a typo in severty:security)
Fixed.
samdark
on 14 Mar 2017
Forgive me if I'm missing something, I'm not sure of the amount of work it requires to do a release, which of course could make such a release schedule a big burden.
Additionally to obvious that's re-checking everything, preparing release (easy part now thanks for @cebe tools), writing and posting announcements (takes time).
samdark
on 14 Mar 2017
Overall, having a schedule is good. I'll put one together.
samdark
on 14 Mar 2017
I would suggest support two branches: feature (master) and maintenance (2.0.x), same as composer (and many other projects) do.
Maintenance branch (2.0.11 for example) contains only bugfixes, and can be released more often (once per week?) as patch releases (2.0.11.1, 2.0.11.2 etc).
Master contains new features and bugfixes merged from maintenance branch. When we release new minor version (for example 2.0.12.0) old maintenance branch (2.0.11) is deleted and we create new maintenance branch (2.0.12). Master will contain features targeted to 2.0.13.0 version.
Little more work with merging, but releases should be more stable and releasing bufixes will be much easier.
rob006
on 14 Mar 2017
Worth trying.
samdark
on 14 Mar 2017
good suggestions. I like the idea to have smaller releases on a regular basis. This is very good for the github flow.
dynasource
on 14 Mar 2017
Thanks for the suggestion. We will definitively be able to release more often starting in April, as me and @samdark will have more time for Yii than before. The last months were a bit complicated for me as I had other priorities which took me away from Yii. That is going to change in April.
cebe
on 15 Mar 2017
samdark
on 18 Jun 2019
Related issues
rosancoderian
路
46Comments
dhiman252
路
44Comments
samdark
路
63Comments
njasm
路
44Comments
Mirocow
路
56Comments
Most helpful comment
Thanks for the suggestion. We will definitively be able to release more often starting in April, as me and @samdark will have more time for Yii than before. The last months were a bit complicated for me as I had other priorities which took me away from Yii. That is going to change in April.