Re: Fix for bug 6075 -- IE6: All day events z-index iss

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 
screwy.


M.

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-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
> 

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

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.

Thanks.


Matthew



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 
> screwy.
> 
> 
> M.
> 
> 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-devlists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
>>
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
> 

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

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.

Thanks.


Matthew



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 
> screwy.
> 
> 
> M.
> 
> 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-devlists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
>>
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
> 

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev