I don’t know if this topic has already been addressed or not, a swift search showed no satisfactionary results anyway.
How do you plan to manage future releases and are there plans to change the commit/pr rules?
One of the issues I had with Yii1 was the slow release of bugfixes/small new features and the relative difficulty of backporting them manually.
1.While it may be essential for the discussion of a pullrequest to see how it evolved, see prior comments on specific sections of code and have others oppinions on them it may clutter the projects history later and make it harder to revert the changes by standard git means (One has to manually create a reverting commit that covers all changes that may be split up in x commits instead of simply doing "git revert xxxxx")
More importantly it makes forward and backward porting of bugfixes harder.
Imagine the following situation:
I’m running a yii2 application using the latest release, which is 2.0.1@stable. However, this release contains a bug that was already fixed on master(or 2.0.x-dev, however releases are managed after ga). While the bug is not severe enough to trigger another release I need the fix (for whatever reason).
My options are now:
[list=1]
[*]Wait (not possible or has serious drawback)
[*]Port the fix over by copy+paste (My branch/repository becomes incompatible with the official one)
[*]Manually picking the git commits into my branch (If done correctly and no conficts emerge on master I can still update to 2.0.2 without having to worry about the merge
[/list]
Doing the third is a mess if a single change consists out of several commits. Having selfcontained commits would also ease 3rd party reviews (company internal) and allow partial updates in quality-ensured environments.
Should it be required to squash pull requests (just)before merge?
Additionally this would allow changelog generation from the commit history. A cleaner look when reviewing the commit log.
Nevertheless, this would require better commit messages and better commiter morale (do not update two unrelated things in a single pr, etc…) Messages like this should be avoided (Don’t worry about calling names. This is a commit made by me).
I’m relativly sure that most of this(alteast the squashing and committing part) could be handled in a more or less simple script or application that can be run by core members).
2. Release more often.
(Naming scheme used: Major.Minor.Patch (x.y.z))
I’d like to have regular scheduled releases, this doesn’t necessarily include minor or major releases but the patch level. Like targetting a z-release for each stable branch in the first week of the month(while having three weeks of development and one week of stabilizing). It shouldn’t matter if only one minor bug was fixed or 100 small enhancements were made(well, maybe have a longer testing period then) to justify a new tag/release.
[b]
How do you aim to manage releases and branches after the first stable (2.0.0) version?[/b]
I’d like to hear some thoughts and oppinions on this 
Do I think in the wrong direction(it’s a muggy sunday) or does it make sense?