lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Proposal about Version API "relaxation"
Date Sun, 25 Apr 2010 12:24:16 GMT
That sounds good to me too.

On 4/25/10 6:58 AM, Michael McCandless wrote:
> Maybe we can leave unstable on its own branch, and stable remains on
> trunk, like it is today?
>
> And, it's not the committer's job to port each little commit to stable
> over to the unstable branch.  Instead, we periodically re-sync stable
> -->  unstable, like we did with the long-lived flex branch.
>
> So, then, little would change on how stable is developed, today.  And
> stable would still be the primary source line for development.
>
> Unstable changes would happen on the unstable branch, and only be
> merged back to trunk when it's time for the next major release.
>
> Mike
>
> On Thu, Apr 22, 2010 at 11:31 AM, Mark Miller<markrmiller@gmail.com>  wrote:
>> Right - that sounds good to me. And when its a hairy change to back port, or
>> the change is just really invasive, or breaks back compat in way you have to
>> jump over hoops to put into stable - then you just put it in unstable. But
>> generally that is not most changes.
>>
>> On 04/22/2010 10:08 AM, Earwin Burrfoot wrote:
>>>
>>> Okay, let's live with parallel development, but make sure we 'always'
>>> port things from stable to trunk, and 'always' remove possible
>>> back-compat layers when doing such a port?
>>>
>>> On Thu, Apr 22, 2010 at 18:04, 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>


-- 
- Mark

http://www.lucidimagination.com

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


Mime
View raw message