Andrew C. Oliver wrote:

>On Sun, 2002-04-21 at 10:47, Marc wrote:
>
>>Andrew C. Oliver wrote:
>>
>>>Hi All and especially those of you who ride Kangaroos to work everyday,
>>>
>>>It occurs to me that some of the things I'm about to do are heavily
>>>HSSF-2.0 oriented and yet I'm not yet sure we'll be ready for 1.5. 
>>>Everytime I think we're RealClose(tm) a Gigantic moth sized anywhere
>>>
>>>from little to gigantic flies into the works and gums them all up.  So
>>
>>>"to branch or not to branch" that is the question!  
>>>
>>>Secondly, after we release 1.5, we'll undoubtedly have a 1.5.1 or
>>>something of the such to capture bug fixes/etc.  So the question before
>>>you:  
>>>
>>>do we create a branch for 1.5 and continue all bug fixes there while
>>>continuing further development on the head.
>>>
>>>I vote +1 - if Glen doesn't have the necessary CVS-foo I'll fake it. ;-)
>>>
>>>Later votes or discussions can determine the status of particular pieces
>>>of code.  I say all formula related stuff goes in the head and not in
>>>1.5.
>>>
>>>-Andy
>>>
>>There are certain practices that I feel must be justified to the 
>>satisfaction of everyone actively on a project -- deliberately violating 
>>encapsulation is one example. Branching is another. It can be (and 
>>usually is) a collossal headache and it is something that I will 
>>grudgingly admit *might* be an acceptable practice after a major 
>>release, to allow for bug fixes while new development continues.
>>
>>This does not sound like such a case.
>>
>>So, I vote -1.
>>
>>I can be persuaded by a convincing argument to retract that vote. Such 
>>an argument should include a restatement of our 1.5 objectives and why 
>>1.5 is being treated as if it were a major release, and why the new work 
>>cannot be performed while 1.5 bug fixes are applied. Also, how about an 
>>explanation of what that new work is?
>>
>
>1.5 - we've got major bugs and minor bugs and the big packaging issue
>that is not captured in 1.0.2
>
>development builds should have formulas enabled... 1.5 should not.  I'm
>queuing patches that will make major changes to formula support. 
>Libin's patches for Named ranges break some charting unit tests (no idea
>why yet) and I really don't think those should go in a "production"
>release.
>
>1.5 is intended to be a production release.  That being the case the
>inevitable 1.5.1 should be a production release.  Development builds
>will start to have things in them that are totally NOT ready for
>production (formula stuff especially) and 1.5.1 should not capture those
>changes.  
>
>We're only talking about 1 branch.  Not two.  And only MINOR changes
>will happen to the 1.5 branch...bugfixes, etc.  (because the dev work
>will continue at the HEAD)/
>
>Thoughts?
>
>>Not trying to be a PITA (when it comes naturally, there's no need to 
>>*try*), but this is a rather serious action we're contemplating, and I 
>>cannot endorse it, indeed, I must oppose it, absent serious discussion.
>>
ok, I guess I'm convinced, then, that 1.5, despite its untraditional 
nomenclature (I think of major releases as n.0 versions), 1.5 is really 
a major release. That being the case, I strongly suggest that, as soon 
as we're all on board with your proposal, we get a binding agreement as 
to what has to be done to get 1.5 out the door, and that we put 
everything else on hold until 1.5 is released.

And, I hereby rescind my -1 vote.

I vote +1

Marc


Reply via email to