lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Proposal about Version API "relaxation"
Date Thu, 22 Apr 2010 18:18:59 GMT
Merging a change is far less than double the effort...

The first time around you had to type each character yourself, create
tests from scratch, fix the failures, post patches, respond to
feedback, iterate like crazy, maybe throw it all over and start over,
etc.

The second time around "svn merge" does all of this in one go.

Yeah you can get conflicts on merging, but (as much as we like to
complain about them), resolving them is usually fast.

It took ~6 hours for us (Uwe, Robert, Mark, myself) to merge flex back
to trunk...

If the unstable line (trunk) diverges too much from stable then
merging does get more costly... but that's probably a good sign that
we should do a major release.

Mike

On Thu, Apr 22, 2010 at 10:16 AM, Shai Erera <serera@gmail.com> wrote:
> But I thought that was the whole point - get rid of Version and loosen on
> the bw policy to not be so restrictive on API. We can finally move to use
> interfaces, stop that API refactoring and deprecation (as one said on a blog
> - "orgy"). If we adopt Mike's proposal, where does it leave us - 99% of the
> development double the efforts, and that tiny percentage like flex (even
> though it's a huge feature in and on itself) having easier life?
>
> Perhaps I'm missing something, but if that's what is proposed and meant, I
> think that not changing anything will (surprisingly and confusingly !) make
> our life easier ...
>
> So Mark, I have to agree w/ you: "If we take that route, I am vehemently
> against changing our policy." +1 !
>
> Shai
>
> On Thu, Apr 22, 2010 at 5:04 PM, Mark Miller <markrmiller@gmail.com> wrote:
>>
>> I'd vote -1 on Shai's variation and +1 on Mike's proposal.
>>
>> I don't think features should be backported to stable on request. If we go
>> this route, I think it should be a matter of course unless the feature is
>> hairy enough to warrant unstable.
>>
>> Saying we should do all dev on unstable, and only back port on request
>> (who will police that? everyone will accept all requests?) and that we
>> should just release trunk more often to accommodate, is like saying, lets
>> just throw back compat out the window, every release will be free to break
>> back compat, we will just release more often...
>>
>> Working on two branches won't be 100% joy, but loosening the existing much
>> larger annoyance of back compat is not going to be free IMO. To me, Shai's
>> proposal is essentially - lets keep everything the same, but release more
>> often (we have decided to that 100 times) and lose back compat requirements.
>> Then if a dev takes pity on a user, perhaps one of the unstable releases
>> will get a backport of a feature.
>>
>> If we take that route, I am vehemently against changing our policy.
>>
>> On 4/22/10 9:52 AM, Shai Erera wrote:
>>
>> I was advocating that we always develop on trunk w/ no back-compat
>> support, API-wise ... you could have developed flex w/ no bw support.
>>
>> Currently what you're proposing would cause most features to be developed
>> on stable w/ bw support and trunk w/o. I propose to leave 'stable', develop
>> on trunk w/ no bw support (except for index format) and back port features
>> "on demand" to stable w/ bw support.
>>
>> So instead of forcing all development to go through stable + trunk, I
>> propose to go through trunk, and back port to stable only if requested. In
>> the end we'll be in the same position (trunk having all features) except for
>> stable which will include just those features of interest to other people.
>>
>> Shai
>>
>> On Thu, Apr 22, 2010 at 4:12 PM, Michael McCandless
>> <lucene@mikemccandless.com> wrote:
>>>
>>> On Wed, Apr 21, 2010 at 1:56 PM, Shai Erera <serera@gmail.com> wrote:
>>>
>>> > The only downside is that we will need to do everything twice: once on
>>> > stable and once on trunk. I still think that most of the issues and
>>> > development don't affect bw at all and thus we'll always say "this
>>> > needs to go to stable and trunk" which will just be an annoyance and
>>> > complicate the life of the developers even more because not only will
>>> > we need to keep bw compat, we'll need to write the code for trunk as
>>> > well.
>>>
>>> Well, most things.  Some features (eg flex would've been such a
>>> feature) will only happen in trunk.
>>>
>>> But, yes, this is a downside -- stable changes will have to be merged
>>> up to trunk.
>>>
>>> > What if we always develop on trunk, release it more often, and if
>>> > requested or a committer needs it, we backport a certain feature to
>>> > stable?
>>>
>>> This is what we do today, and I think what's broken about it is we are
>>> unable to make a big change that has major breaks from the start.
>>> Every big change is required to land on trunk with back compat intact.
>>>
>>> This is terribly costly for changes like the new analyzer API (Token
>>> -> AttrSource migration), and flex.
>>>
>>> So with the new model, a big change like flex could land on trunk with
>>> no back compat, and age for a long time, along with other such
>>> changes, before being included in a major release.
>>>
>>> I'm not sure we'll release trunk (major releases) more often.  I think
>>> it could go both ways...
>>>
>>> For small changes, I think whether a given dev works on trunk and
>>> merges back to stable, or stable and merges forwards to trunk, is an
>>> individual choice...
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>
>

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


Mime
View raw message