Maybe we should not make a decision right now? We've talked over the proposals, and there are pros and cons to each, and clearly two sides. I think at this point we just have to "try it", whatever "it" is and see if that works and how it plays. It's like software design - we've played w/ some ideas, now we need to do some coding and get back to the drawing board and see what played well and what needs revisiting.
So maybe, as an exercise, we should not *really* change anything but do what was raised on another thread --> branch off pre-flex. Allow some time for people to backport contributions they've made post-flex to that branch. Especially contributions which do not depend on flex. Then we call that branch 3.1. The exercise will tell us (to some degree) how much interest is there in backporting. If only few issues will be backported (I plan to do some), then the result is not unequivocal. However if we see many of the contributions are backported, we can at least assume it will be so in the future as well, because there is interest. Then, we can come back to this thread and decide what to do w/ flex (which will live in trunk, still) -- should be it the next 4.0, or maybe the decision will change and it will be the next 3.2. Since flex is already backported, we don't lose anything. If the decision will be to make it 4.0, then some work will be done to get rid of the back-compat layers, perhaps clean the API etc. Otherwise, it will leave in trunk for some more time for people to more easily consume it. If another such great feature comes along (which is expected to change a lot of code), I think it'd be safe to start developing it w/ no back-compat in mind anyway, irregardless of the policy ... What do you think? Shai On Sun, Apr 25, 2010 at 11:31 PM, Mark Miller <markrmil...@gmail.com> wrote: > On 4/25/10 4:10 PM, Shai Erera wrote: > >> I think that we agree in principal about the policy change. We seem to >> disagree only on where should the default dev should be: trunk or >> branch. >> > > Right. > > > >> So why not put it up to the test? Let's declare that all dev happens >> on trunk. If few features are backported - then it means (probably) >> that there is not much interest in backporting. If many features are >> backported, it means not only people want to backport, but also >> committers are willing to help do that. Feels to me like a win-win >> situation for both arguments. >> > > I still don't like "just seeing what happens". What we all agree should be > best for users as well as devs is not always going to be in alignment with > letting the chips fall where they may. I don't think seeing whether > committers just do something individually/naturally is a good test for > whether we have the right goals for the project. > > Deciding if we should have the back compat police is not something we would > do by saying "Okay, no more back compat policy - lets just see if devs do > back compat on there own or not - if they do, we bring back back compat". > Natural inclinations and unofficial 'policy' are two very different things - > and I think both are important. Natural inclination doesn't sound exactly > like the right test for official/unofficial/loose policies that are meant to > guide natural inclinations. Despite Roberts complaining, we don't have many, > but we do have some - without our back compat policy, upgrading code that > extensively uses Lucene would have been extremely difficult. When you are > avoiding deprecation, and deprecation releases and increasing the number and > size of complicated changes, you make upgrading more and more difficult. 2.9 > to 3.0 was already no cakewalk, but if you did it right, Lucene walks you > right through all the changes you need to grapple with, and points you along > the path. This will all essentially go away. The least we can do is provide > solid stable releases, and are informally dedicated to doing such - by > putting all dev that fits into stable. > > > >> So instead of being strict right from the start, we try to be more >> agile and responsive. We don't unnecessarily burden the committers >> with the tedious job of merging svn every time, but instead verify >> first that what we think is requested by the people, actually is >> requested. >> > > I'm totally against this whole "request" idea. Things that make sense to go > to stable should go to both. Things that make sense to go to unstable should > go there. Some people I think put dev annoyances over a good user experience > - personally I think their should be more of a balance. What's easy for devs > is not always easy for users - otherwise this would have been a free for all > from the beginning. We would have done away with all of the 'burdens', > 'annoyances', and 'tediousness'. And just shoved them off to users that > where trying to upgrade their code to use the latest Lucene. The two need to > be balanced. > > > >> As Mark indicated, the current back-compat policy was never voted on. >> Instead it made sense and thus was applied. Maybe we're wrong :)? >> > > No we where not wrong. That back compat policy has worked out for a long > time. Evolving policy is going to be natural as the situation changes. That > doesn't mean it should evolve to nothing or anything just because its > changing. And the current back compat policy was not officially voted on > (which only the PMC can do), but it was voted on with action over time. Same > as its been loosened over time. > > > >> Let's be bold, do some change and then reflect back on it and decide >> if it was smart or not. It's not like the process is irreversible - on >> the contrary, what I'm suggesting is essentially what's done today >> (svn-wise) and thus can easily be changed in the future. While if we >> start w/ Mike's proposal, changing it would be more confusing to the >> people, and will probably also generate such a huge thread … >> > > But I don't agree that the path you want is the right path. So why be > "bold" about it? > > What would be "confusing to the people"? > > How is this the process we currently use? The current process is that bugs > that should be back ported are back ported. Sometimes their are requests for > further back ports, but the general policy is to back port what makes sense, > not what is requested. And that's been being done for some time. > > > >> Shai >> >> On Sunday, April 25, 2010, Mark Miller<markrmil...@gmail.com> wrote: >> >>> On 4/25/10 1:43 PM, Michael McCandless wrote: >>> >>> >>> Changes that go into stable need to be merged to unstable, maybe >>> periodically sweeped or maybe merged up by the original committer or >>> likely some combination (like flex). >>> >>> (And, yes we'll still use other branches for big new features that are >>> in active development). >>> >>> Mike >>> >>> >>> >>> I'm still +1 on all the proposals you have made. And still -1 to most of >>> the attempted tweaks on them that have been proposed :) >>> >>> -- >>> - 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 >> >> > > -- > - Mark > > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
