Hy Darby,
I was not able to see the branch 1.0.1... only the old branch 1.0
There is no 1.0.1 branch. The 1.0.1 release will be tagged from the
release-1.0 branch. A 1.0.2 release, though we may not have one before
1.1.0, would also be produced from this branch. When 1.1.0 is
approaching, we'll create a release-1.1 branch, from which 1.1.0, 1.1.1,
etc. would be tagged. This is illustrated with an image in the lifecycle
document. (We _could_ create further release branches, such as for 1.0.1
and 1.0.2 separately, but such additional complexity is probably not
warranted for this project at this time.)
So we should always use the Zend Branch 1.0 when committing as long as its
for fixing bugs.
Right ? But only if it has been reviewed by someone.
The next point is that we have first to find a zend member who looks
through the changes before we commit them.
No, in most cases, you can simply have another contributor review your
work. Of course, you can always ask a Zend liaison to review your work,
but we have limited bandwidth, and we have to delegate as much of this
work as possible to the community itself. We just want to make sure that
unit tests pass and that the changes have been reviewed for potential
risks to stability before they are merged on to a release branch.
And exact here is my personal problem ;-)
I am the main author and only person who codes all the I18N classes.
There is no other contributor. So I must ask Zend to review my code.
JIRA issues can be resolved as soon as passing unit tests for the fix
are committed to the trunk, though the issue should be marked as fixed
for the affected versions. (For us right now this means that resolving
an issue in the trunk fixes 1.1.0, and once the changes are merged to
the release branch, it would also fix 1.1.1.)
And what about fixes which do not include unit tests ?
For example...
I am not able to write tests for issues which are related to 64bit machines
only
or for race conditions.
Should they also be reviewed by a Zend member ?
As mentioned in the lifecycle document, no documentation is to be merged
to release branches. Documentation improvements will go out with minor
and major releases (e.g., 1.1.0 and 2.0.0, respectively).
But should new documentation be reviewed by Zend ???
It depends on the scope of the work and how long you expect the work to
take. We don't want you to be stuck holding back committing your
incomplete work. If you write 200 lines of code today, you should have a
place to commit it, even if it is not complete. This creates an instant
backup and facilitates review before completion.
When I integrate new features to a class I can not committ only parts....
This would brake the existing class in the trunk or incubator.
And I dont want to get flamed for things which I know not to work for now.
Coding a new class for example is no problem...
but changing existing classes is a problematic thing.
The other thing is that I can not code every day...
often I have several days where no progress is done.
I think noone would be happy if I for example integrate the new
SQL-translate
adapter but the base class work not anymore in incubator because I commited
to early.
I don't know about eclipse specifically, but you can switch a single
working copy between two branches. Again, this is documented in the
lifecycle document; perhaps some elaboration is needed to make it more
clear? To strike a balance, we also do not want to be overwhelmingly
verbose, but where clarifications can be made, all the better. :)
No I can not...
For example Zend_Date....
I've integrated new features (array access).
But when there is a new bug I have to integrate it in
trunk (where the new feature resists) and in maintenance.
Otherwise the maintenance branch would also have the
new feature integrated which is not allowed.
As in maintenance no new features are being integrated
this is the only possible way as I see it.
Ok...
So who can review my changes since the last release ?
I've made several changes and bug fixes which should be integrated.
Greetings
Thomas
I18N Team Leader
