Hi Fabien,
I would suggest that all changes that you would like to have in the
1.0.1 release should receive at least a cursory review (from another
community member and/or Zend) before merging the changes to the stable
release branch. Particularly risky changes should receive special
attention, since they may affect the stability of the 1.0.1 release if
such changes are merged to the release branch. Good unit tests and peer
review help to mitigate these risks.
If there are changes that you think should wait until 1.1.0, then it
should be fine to forgo such review, since the changes would not be
merged to the release branch, but keep in mind that we have to consider
each commit on a case-by-case basis.
The extra process is necessary to maintain stability of the release
branch and, therefore, the quality of the 1.0.1 release.
Best regards,
Darby
Fabien MARTY wrote:
Hi Darby,
[...]
Therefore, once you have committed
changes to the trunk with passing unit tests, please request review from
a community member or a Zend liaison, and then merge the changes (except
for documentation) to the release branch.
[...]
It doesn't sound very clear to me.
Let's take an example.
I commited some bug fixes into the trunk :
- (1) some of them should be commited (IMHO) into the release branch
- (2) some of them are not really important and can wait the 1.1.0
- (3) some of them are potentially dangerous
All of them are available in JIRA.
= May I commit (1) directly (without any review) ? (if not, it will
be very frustrating think for personal contributors like me)
= No problem for (2), they are waiting in the trunk
= A review is mandatory to commit (3)
Are you ok with these 3 points ?
