Right, and we'd remove the 2 non-sophisticated :) back compat layers in flex, and I'd make an index migration tool for 4.0.
Mike On Mon, Apr 26, 2010 at 11:12 PM, Shai Erera <[email protected]> wrote: > I would like to think that if 3.1 is cut w/o flex (and following dependent > issues), then we will allow people to re-commit the already committed code > changes to the 3.1 branch before it is released. Then, flex et al. become > the next 4.0 and 3.1 will be the first minor stable release of 3.x w/ some > of the features that came post-flex (exercising our svn merge skills :)). > > Shai > > On Mon, Apr 26, 2010 at 11:01 PM, DM Smith <[email protected]> wrote: >> >> Assuming that the vote passed: I'm wondering where this leaves us for the >> near term? How it works in practice. >> >> There have been a lot of recent changes and flex has landed. There are a >> bunch of issues marked as 3.1 and many (most?) have decent patches. >> >> Let's suppose a 3.1 release soon. What would it be/contain and how would >> it work? >> >> -- DM >> >> On 04/26/2010 03:55 PM, Shai Erera wrote: >>> >>> An interesting point was made on Version - we cannot remove it from >>> trunk just to reintroduce it when trunk is released as .0 and then >>> followed by .1 .2 "stable" releases … otherwise it would >>> appear/disappear constantly :)? >>> >>> So I guess Versuon should go away entirely? >>> >>> Shai >>> >>> On Monday, April 26, 2010, Michael McCandless<[email protected]> >>> wrote: >>> >>>> >>>> This is exactly the intention behind the proposal we are voting on. >>>> >>>> Big changes, that'd be destabilizing if attempted on the stable >>>> branch, would be done only on unstable (= trunk). >>>> >>>> More "normal" changes, which can still include deprecations/some back >>>> compat, would be done on the stable branch and unstable. >>>> >>>> So, eg, rather than attempt back compat for a big change like flex, we >>>> would instead do it only in unstable and it'd first become "available" >>>> in the next .0 release. >>>> >>>> By segregating the big changes away from stable we should be able to >>>> keep stronger back compat on stable. We also save our resources not >>>> building costly back compat layers that, because of their complexity, >>>> bring their own problems. Also, our release numbers are more >>>> "standard" -- the .0 release will have major changes (unlike today >>>> where is has no changes except removal of deprecations). >>>> >>>> Mike >>>> >>>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<[email protected]> >>>> wrote: >>>> >>>>> >>>>> On 4/26/10 2:43 PM, Chris Hostetter wrote: >>>>> >>>>>> >>>>>> My best guess: that what this is really suggesting is that "trunk" >>>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0, >>>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; >>>>>> 4.1., >>>>>> 4.2, etc...) happen on "more stable" branches off of the major version >>>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release, >>>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...) >>>>>> >>>>> >>>>> This is what I would like. Not sure if that's what will come from the >>>>> current proposal or not, but seems so to me. >>>>> >>>>> -- >>>>> - Mark >>>>> >>>>> http://www.lucidimagination.com >>>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
