Re: [DISCUSSION] Trunk and Stable release strategy
+1 Makes sense to me. On Jan 24, 2011, at 4:07 AM, Shai Erera wrote: Hi Few days ago Robert and I discussed this matter over IRC and thought it's something we should bring forward to the list. This issue arise due to recent index format change introduced in LUCENE-2720, and the interesting question was if we say 4.0 is required to read all 3x indexes, how would 4.0 support a future version of 3x, that did not even exist when 4.0 was released. Trunk means the 'unstable' branch (today's 4.0) and Stable is today's 3.0, but the same issue will arise after we make 4.0 Stable and 5.0 Trunk. After some discussion we came to a solution that we would like to propose to the list: we continue to release 3x until we stabilize trunk. When we're happy with trunk, we release it, say 4.0, and the last 3x release becomes the bug fix release for 3x and from that point we maintain 4.0 (new features and all, while maintaining API back-compat) and Trunk becomes the next big thing (5.0). There won't be interleaving 4.0 and 3x releases and we won't reach the situation where we released 4.0 and then release 3.2, w/ say index format change (that we just had to make). While we can say 3x can be released after 4.0 w/ no index format changes whatsoever, we think this proposal makes sense. There's no point maintaining 2 stable branches (3x and 4x) and an unstable Trunk. This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. What do you think? Shai - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[DISCUSSION] Trunk and Stable release strategy
Hi Few days ago Robert and I discussed this matter over IRC and thought it's something we should bring forward to the list. This issue arise due to recent index format change introduced in LUCENE-2720, and the interesting question was if we say 4.0 is required to read all 3x indexes, how would 4.0 support a future version of 3x, that did not even exist when 4.0 was released. Trunk means the 'unstable' branch (today's 4.0) and Stable is today's 3.0, but the same issue will arise after we make 4.0 Stable and 5.0 Trunk. After some discussion we came to a solution that we would like to propose to the list: we continue to release 3x until we stabilize trunk. When we're happy with trunk, we release it, say 4.0, and the last 3x release becomes the bug fix release for 3x and from that point we maintain 4.0 (new features and all, while maintaining API back-compat) and Trunk becomes the next big thing (5.0). There won't be interleaving 4.0 and 3x releases and we won't reach the situation where we released 4.0 and then release 3.2, w/ say index format change (that we just had to make). While we can say 3x can be released after 4.0 w/ no index format changes whatsoever, we think this proposal makes sense. There's no point maintaining 2 stable branches (3x and 4x) and an unstable Trunk. This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. What do you think? Shai
Re: [DISCUSSION] Trunk and Stable release strategy
That all makes perfect sense to me +1 simon On Mon, Jan 24, 2011 at 10:07 AM, Shai Erera ser...@gmail.com wrote: Hi Few days ago Robert and I discussed this matter over IRC and thought it's something we should bring forward to the list. This issue arise due to recent index format change introduced in LUCENE-2720, and the interesting question was if we say 4.0 is required to read all 3x indexes, how would 4.0 support a future version of 3x, that did not even exist when 4.0 was released. Trunk means the 'unstable' branch (today's 4.0) and Stable is today's 3.0, but the same issue will arise after we make 4.0 Stable and 5.0 Trunk. After some discussion we came to a solution that we would like to propose to the list: we continue to release 3x until we stabilize trunk. When we're happy with trunk, we release it, say 4.0, and the last 3x release becomes the bug fix release for 3x and from that point we maintain 4.0 (new features and all, while maintaining API back-compat) and Trunk becomes the next big thing (5.0). There won't be interleaving 4.0 and 3x releases and we won't reach the situation where we released 4.0 and then release 3.2, w/ say index format change (that we just had to make). While we can say 3x can be released after 4.0 w/ no index format changes whatsoever, we think this proposal makes sense. There's no point maintaining 2 stable branches (3x and 4x) and an unstable Trunk. This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. What do you think? Shai - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [DISCUSSION] Trunk and Stable release strategy
Hi Shai, I am fine with that, we can still support 3.y [y means the version that was at this point released] after a release of 4.0 but no new features or non-bug-fixes. This means a change like the index format change would not be allowed for 3.y after 4.0 was released. So +1 for this strategy! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Monday, January 24, 2011 10:08 AM To: dev@lucene.apache.org Subject: [DISCUSSION] Trunk and Stable release strategy Hi Few days ago Robert and I discussed this matter over IRC and thought it's something we should bring forward to the list. This issue arise due to recent index format change introduced in LUCENE-2720, and the interesting question was if we say 4.0 is required to read all 3x indexes, how would 4.0 support a future version of 3x, that did not even exist when 4.0 was released. Trunk means the 'unstable' branch (today's 4.0) and Stable is today's 3.0, but the same issue will arise after we make 4.0 Stable and 5.0 Trunk. After some discussion we came to a solution that we would like to propose to the list: we continue to release 3x until we stabilize trunk. When we're happy with trunk, we release it, say 4.0, and the last 3x release becomes the bug fix release for 3x and from that point we maintain 4.0 (new features and all, while maintaining API back-compat) and Trunk becomes the next big thing (5.0). There won't be interleaving 4.0 and 3x releases and we won't reach the situation where we released 4.0 and then release 3.2, w/ say index format change (that we just had to make). While we can say 3x can be released after 4.0 w/ no index format changes whatsoever, we think this proposal makes sense. There's no point maintaining 2 stable branches (3x and 4x) and an unstable Trunk. This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. What do you think? Shai
Re: [DISCUSSION] Trunk and Stable release strategy
On Mon, Jan 24, 2011 at 4:07 AM, Shai Erera ser...@gmail.com wrote: This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. +1, this way development is simple: we are always working on the next big release in trunk (for incompatible changes), and port compatible changes back to the next minor release. this seems to be working now, so lets stick with what works. when we release 4.0, 3.x goes into bugfix-mode like 2.9 is now, we start working on 5.0 in trunk, and open up branch_4x to backport compatible changes (e.g. for 4.1) also, I think its simpler to users: no confusion such as 4.1 not being able to read 3.4 indexes or similar silliness: to the users the versions are still completely sequential. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [DISCUSSION] Trunk and Stable release strategy
+1 Mike On Mon, Jan 24, 2011 at 8:32 AM, Robert Muir rcm...@gmail.com wrote: On Mon, Jan 24, 2011 at 4:07 AM, Shai Erera ser...@gmail.com wrote: This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. +1, this way development is simple: we are always working on the next big release in trunk (for incompatible changes), and port compatible changes back to the next minor release. this seems to be working now, so lets stick with what works. when we release 4.0, 3.x goes into bugfix-mode like 2.9 is now, we start working on 5.0 in trunk, and open up branch_4x to backport compatible changes (e.g. for 4.1) also, I think its simpler to users: no confusion such as 4.1 not being able to read 3.4 indexes or similar silliness: to the users the versions are still completely sequential. - 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
Re: [DISCUSSION] Trunk and Stable release strategy
Glad that we reached consensus on this one so quickly :). Another thing - I think it'd also make sense to stop fixing bugs on 3.0 once we release 3.1. That way, we can have bug-fix releases for 2.9 and latest released 3.x. We then have two options about 3.0.4 (not yet released): 1) Release it (as it includes some bug fixes) and say this will be the last 3.0.x release. 2) Don't release it and say any bugs found in 3.0 are either fixed in 3.1 or will be fixed in 3.1.x. I personally don't have any strong feelings about either option, but option #2 involves much less efforts :). Shai On Mon, Jan 24, 2011 at 3:50 PM, Michael McCandless luc...@mikemccandless.com wrote: +1 Mike On Mon, Jan 24, 2011 at 8:32 AM, Robert Muir rcm...@gmail.com wrote: On Mon, Jan 24, 2011 at 4:07 AM, Shai Erera ser...@gmail.com wrote: This will allow us to release 3x as frequent as we want, hold on w/ trunk as much as we want, and at some point cut over to 4.0 and think about the next big things we'd like to bring to Lucene. +1, this way development is simple: we are always working on the next big release in trunk (for incompatible changes), and port compatible changes back to the next minor release. this seems to be working now, so lets stick with what works. when we release 4.0, 3.x goes into bugfix-mode like 2.9 is now, we start working on 5.0 in trunk, and open up branch_4x to backport compatible changes (e.g. for 4.1) also, I think its simpler to users: no confusion such as 4.1 not being able to read 3.4 indexes or similar silliness: to the users the versions are still completely sequential. - 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
