One thing we could do that might help releases is to isolate
new/improved feature work to branches only, before merging to master,
and establish a development schedule, not just a release schedule.
We can put bug fixes in master, but new features really shouldn't be
put in master until they are ready for inclusion in a release. This
makes it easier to roll back incomplete features, but makes it harder
to review/test multiple branches to determine if it's ready for
inclusion in a release.
This model would probably require more people to be proactive about
evaluating the state of multiple feature branches, so follow-on
quality/usability/implementation improvements can be made before
merging to master.
One thing that might help is to establish a development schedule. At
30% through the dev schedule, features could be assessed (by self-eval
and soliciting feedback) for additional improvements/changes. If they
aren't ready for assessment, then they get punted to the next version.
Whatever comes out of the assessment can be worked until 60% of the
dev schedule, at which point we determine whether they are ready for
inclusion in a release. If not, they are punted to the next version.
However, if they are ready, then the remaining 40% would be
integration to the master branch, testing and bug fixes. Any suggested
non-bugfix improvements found after the choice to include would have
to go in the next version.
Formally, the 60% mark would be feature freeze. These numbers are also
just rough guesses for what might work, and this is just an unpolished
idea, though. This might only be applicable to major features, but if
we operate this way for all new features/improvements, it could also
help avoid the situation where we didn't realize that a minor feature
would be turn into a major one.
Christopher L Tubbs IIhttp://gravatar.com/ctubbsii
On Thu, Mar 13, 2014 at 12:21 PM, Keith Turner <[EMAIL PROTECTED]> wrote: