Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 11604 invoked from network); 27 Apr 2010 03:13:26 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 27 Apr 2010 03:13:26 -0000 Received: (qmail 75826 invoked by uid 500); 27 Apr 2010 03:13:25 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 75451 invoked by uid 500); 27 Apr 2010 03:13:25 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 75444 invoked by uid 99); 27 Apr 2010 03:13:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Apr 2010 03:13:24 +0000 X-ASF-Spam-Status: No, hits=1.9 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of serera@gmail.com designates 72.14.220.156 as permitted sender) Received: from [72.14.220.156] (HELO fg-out-1718.google.com) (72.14.220.156) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Apr 2010 03:13:20 +0000 Received: by fg-out-1718.google.com with SMTP id l26so1098610fgb.5 for ; Mon, 26 Apr 2010 20:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ZJtKfj1ZMC1GLW8wdiyaHrWPIOCDNnMp1bRmbQsME7k=; b=H5XjhNb+ZiCntAY6xxOKIr/PTsNCnpZmAILcJbJOv/KRY7iUZZ/Xrd2157sbjzbYf6 radyA9QD+8feuyYDDYA04FbR/Iida+HlfAsGpxb3P9eUwBL3QnRwsHVkYmcYY8FgAHE7 Szav3xWb60eYizuMi27XLHwAS9/oKhrMFNx+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OLNJ/wnWjEtLc1hI7AqaEpQ6LbuNGfFMongTnZttjYQ9D+Bp/PiQg40PIJ+YFOrBQ5 7ct6nZFr5InSLWjheCkmBQ50TnWK4zSmi5Po+bIbtRo+vMdHqr5MFNMu4p0SvhvTMBKR gb1hvrhUBrWH7JmcHD0fneeMyNof0f9B9nGa8= MIME-Version: 1.0 Received: by 10.103.126.31 with SMTP id d31mr2810203mun.49.1272337978554; Mon, 26 Apr 2010 20:12:58 -0700 (PDT) Received: by 10.103.39.4 with HTTP; Mon, 26 Apr 2010 20:12:58 -0700 (PDT) In-Reply-To: <4BD5F126.1050407@gmail.com> References: <4BD5E1B9.2070802@gmail.com> <4BD5F126.1050407@gmail.com> Date: Tue, 27 Apr 2010 06:12:58 +0300 Message-ID: Subject: Re: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development From: Shai Erera To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary=0016e65bce403efbb804852f452f --0016e65bce403efbb804852f452f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 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 =85 otherwise it would >> appear/disappear constantly :)? >> >> So I guess Versuon should go away entirely? >> >> Shai >> >> On Monday, April 26, 2010, 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 (=3D 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 >>> 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 versio= n >>>>> 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-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org > > --0016e65bce403efbb804852f452f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I would like to think that if 3.1 is cut w/o flex (and fol= lowing dependent issues), then we will allow people to re-commit the alread= y committed code changes to the 3.1 branch before it is released. Then, fle= x 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 mer= ge skills :)).

Shai

On Mon, Apr 26, 2010 at 11:01 PM= , DM Smith <dm= smith555@gmail.com> wrote:
Assuming that the vote passed: I'm wondering where this leaves us for t= he near term? How it works in practice.

There have been a lot of recent changes and flex has landed. There are a bu= nch 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 woul= d 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 =85 otherwise it would
appear/disappear constantly :)?

So I guess Versuon should go away entirely?

Shai

On Monday, April 26, 2010, Michael McCandless<lucene@mikemccandless.com> =A0w= rote:
=A0
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 (=3D 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 "availa= ble"
in the next .0 release.

By segregating the big changes away from stable we should be able to
keep stronger back compat on stable. =A0We also save our resources not
building costly back compat layers that, because of their complexity,
bring their own problems. =A0Also, our release numbers are more
"standard" -- the .0 release will have major changes (unlike toda= y
where is has no changes except removal of deprecations).

Mike

On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<markrmiller@gmail.com> =A0wrote:
=A0 =A0
On 4/26/10 2:43 PM, Chris Hostetter wrote:
=A0 =A0 =A0
My best guess: that what this is really suggesting is that "trunk"= ;
*always* =A0be 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 ve= rsion
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...)
=A0 =A0 =A0 =A0
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.lu= cidimagination.com
=A0 =A0 =A0


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


--0016e65bce403efbb804852f452f--