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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
