+0.9 What are the requirements of me, "Joe Committer" and of "Joe Contributor" in regards to submitting/committing patches?
For Joe Committer, am I required to put everything on stable and trunk or can I just pick trunk and if someone else wants it they do stable or vice versa? Likewise for Joe Contributor, must I generate two patches now? On Apr 26, 2010, at 3:06 PM, Michael McCandless 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 <markrmil...@gmail.com> 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
