[Cosmo-dev] Re: [commits-cosmo] (mde)  Fix for bug 6075
-- IE6: All day events z-index issue.
mde at osafoundation.org
Tue Apr 3 15:09:03 PDT 2007
If there's no further discussion or action taken, it would seem that
we're choosing the option number 2 that I described in my previous
e-mail. Just to recap:
1. Merge 0.6.1-type changes back to trunk so trunk gets the new
functionality, but *still do the release from the 0.6 branch.* This
would mean that trunk can still have significant changes made to it, and
QA is done to a branch that has already been stabilized. Major dev work
can still be done on trunk.
2. Don't touch trunk after major releases (Like Nigel's Les Paul), since
we may have to base point releases on the state of trunk right after the
release. All new development and non-point-release bugfixes would have
to go in private branches. Those branches would have to be kept in sync
with the trunk, and stuff in them would be selectively merged to trunk
when they're going into a release.
To quote our geek forefathers, "If you choose not to decide / You still
have made a choice." :)
There is some major refactoring associated with some of my bugs (ex.
8491, 7767, 8613), and I'm trying to think ahead to avoid manual
conflict resolutions later.
Matthew Eernisse wrote:
> Do you mean 'next major version,' or does that include point releases
> like 0.6.1? I don't think we'll always know if we're going to have a
> point release or not. So we could end up in a situation again where we
> have to decrement the trunk version number -- which to me seems pretty
> Brian Moseley wrote:
>> i think we should always develop the next version to be released on
>> the trunk, and work on future versions, or experimental work, should
>> be done on branches made from the trunk, not from other branches.
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev