Yep this is the case. We do the same in the PHP project. Actually right
now we have three (4.4.x, 5.2.x and 6.x). There's really no other way
but we will try and aim to only have two at any given time (pray...).
 

> -----Original Message-----
> From: Thomas Weidner [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, July 17, 2007 3:00 PM
> To: Bill Karwin; fw-general@lists.zend.com
> Subject: Re: [fw-general] Re: Lifecycle Handling
> 
> Hy,
> 
> which means that core-contributors have to have two released 
> on their workstations.
> The trunk for new features and the branch for maintenance releases.
> 
> That's what I asked for and noone was able to definitly say yes or no.
> I expect most people would not be very amused if I fix bugs 
> only for 1.1
> (trunk) instead of 1.0.x (branch) ;-)
> 
> Greetings
> Thomas
> I18N Team Leader
> 
> ----- Original Message -----
> From: "Bill Karwin" <[EMAIL PROTECTED]>
> To: <fw-general@lists.zend.com>
> Sent: Tuesday, July 17, 2007 11:15 PM
> Subject: RE: [fw-general] Re: Lifecycle Handling
> 
> 
> 
> > -----Original Message-----
> > From: Thomas Weidner [mailto:[EMAIL PROTECTED]
> >
> > 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.
> 
> This means there are a few choices:
> 
> (a) Implement the same bug fix in a different way, to work 
> with the code
> in the branch.  But depending on the nature of the bug, this 
> may be too
> much work.
> 
> (b) Implement the bug fix in both trunk and branch, 
> implemented in a way
> that doesn't rely on the new features.  Sometimes this is 
> possible, but
> sometimes it's not possible or it's too much work.
> 
> (c) Fix the bug in the trunk but don't fix it in the branch.  
> Users must
> wait until 1.1.0 to get some bug fixes.
> 
> I think all cases will fit into the three choices above.  :-)
> 
> Regards,
> Bill Karwin 
> 
> 

Reply via email to