You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2009/10/13 22:07:46 UTC
Re: Draft for java-user mail about backwards-compatibility policy
changes
Looks good!
Mike
On Tue, Oct 13, 2009 at 3:07 PM, Michael Busch <bu...@gmail.com> wrote:
> Hi all,
>
> I wrote a draft for a mail I'd like to send to java-user to get some
> feedback about the proposed changes to our backwards-compatibility policy we
> discussed here and on LUCENE-1698.
> Let me know what you think please!
>
> Michael
>
>
> Hello Lucene users:
>
> In the past we have discussed our backwards-compatibility policy
> frequently on the Lucene developer mailinglist and we are very tempted
> to make some significant changes. In this mail I'd like to outline the
> proposed changes to get some feedback from the user community.
>
> Our current backwards-compatibility policy regarding API changes
> states that we can only make changes that break
> backwards-compatibility in major releases (3.0, 4.0, etc.); the next
> major release is the upcoming 3.0.
>
> Given how often we made major releases in the past in Lucene this
> means that deprecated APIs need to stay in Lucene for a very long
> time. E.g. if we deprecate an API in 3.1 we'll have to wait until 4.0
> before we can remove it. This means that the code gets very cluttered
> and adding new features gets somewhat more difficult, as attention has
> to be paid to properly support the old *and* new APIs for a quite long
> time.
>
> The current policy also leads to delaying a last minor release before
> a major release (e.g. 2.9), because the developers consider it as the
> last chance for a long time to introduce new APIs and deprecate old ones.
>
> The proposal now is to change this policy in a way, so that an API can
> only be removed if it was deprecated in at least one release, which
> can be a major *or* minor release. E.g. if we deprecate an API and
> release it with 3.1, we can remove it with the 3.2 release.
>
> For users this means of course that a simple jar drop-in replacement
> won't be possible anymore with almost every Lucene release (excluding
> bugfix releases, e.g. 2.9.0->2.9.1). However, you can be sure that if
> you're using a non-deprecated API it will be in the next release.
>
> Note that of course these proposed changes do not affect
> backwards-compatibility with old index formats. I.e. it will still be
> possible to read all 3.X indexes with any Lucene 4.X version.
>
> Our main goal is to find the right balance between
> backwards-compatibility support for all the Lucene users out there and
> fast and productive development of new features. If we get positive
> feedback here we will call a vote on the development mailinglist where
> the committers have to officially decide whether to make these changes or
> not.
>
> Note that in any case the changes will take affect *after* the 3.0
> release.
>
> On behalf of the Lucene developers,
> Michael Busch
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Draft for java-user mail about backwards-compatibility policy
changes
Posted by Andi Vajda <va...@osafoundation.org>.
On Tue, 13 Oct 2009, Mark Miller wrote:
> For the record - I still don't see what we gain but confusion.
>
> The major numbers don't have any significant meaning in terms of
> features or advancements.
That's a perception we don't have control over.
A release incrementing the major release number is considered major whether
we like to think so or not.
If that release only contains backwards compatibility breaking changes and
nothing much else to talk about, it is not that major and is likely to cause
disappointment.
Andi..
> If we want to remove deprecations faster after deprecating in 4.1, we
> should just not release 4.2,4.3,4.4,4.5, and then 4.9.
>
> We should go from 4.1 to 4.9, or 4.1,4.2, then 4.9. We have always just
> chosen how long we were stuck with stuff by how fast we decided to skip
> the dots.
>
>
> Mark Miller wrote:
>> I think it should be more clear that the devs have not come to an
>> agreement on this change yet, irregardless of the communities input.
>>
>> Michael McCandless wrote:
>>
>>> Looks good!
>>>
>>> Mike
>>>
>>> On Tue, Oct 13, 2009 at 3:07 PM, Michael Busch <bu...@gmail.com> wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> I wrote a draft for a mail I'd like to send to java-user to get some
>>>> feedback about the proposed changes to our backwards-compatibility policy we
>>>> discussed here and on LUCENE-1698.
>>>> Let me know what you think please!
>>>>
>>>> Michael
>>>>
>>>>
>>>> Hello Lucene users:
>>>>
>>>> In the past we have discussed our backwards-compatibility policy
>>>> frequently on the Lucene developer mailinglist and we are very tempted
>>>> to make some significant changes. In this mail I'd like to outline the
>>>> proposed changes to get some feedback from the user community.
>>>>
>>>> Our current backwards-compatibility policy regarding API changes
>>>> states that we can only make changes that break
>>>> backwards-compatibility in major releases (3.0, 4.0, etc.); the next
>>>> major release is the upcoming 3.0.
>>>>
>>>> Given how often we made major releases in the past in Lucene this
>>>> means that deprecated APIs need to stay in Lucene for a very long
>>>> time. E.g. if we deprecate an API in 3.1 we'll have to wait until 4.0
>>>> before we can remove it. This means that the code gets very cluttered
>>>> and adding new features gets somewhat more difficult, as attention has
>>>> to be paid to properly support the old *and* new APIs for a quite long
>>>> time.
>>>>
>>>> The current policy also leads to delaying a last minor release before
>>>> a major release (e.g. 2.9), because the developers consider it as the
>>>> last chance for a long time to introduce new APIs and deprecate old ones.
>>>>
>>>> The proposal now is to change this policy in a way, so that an API can
>>>> only be removed if it was deprecated in at least one release, which
>>>> can be a major *or* minor release. E.g. if we deprecate an API and
>>>> release it with 3.1, we can remove it with the 3.2 release.
>>>>
>>>> For users this means of course that a simple jar drop-in replacement
>>>> won't be possible anymore with almost every Lucene release (excluding
>>>> bugfix releases, e.g. 2.9.0->2.9.1). However, you can be sure that if
>>>> you're using a non-deprecated API it will be in the next release.
>>>>
>>>> Note that of course these proposed changes do not affect
>>>> backwards-compatibility with old index formats. I.e. it will still be
>>>> possible to read all 3.X indexes with any Lucene 4.X version.
>>>>
>>>> Our main goal is to find the right balance between
>>>> backwards-compatibility support for all the Lucene users out there and
>>>> fast and productive development of new features. If we get positive
>>>> feedback here we will call a vote on the development mailinglist where
>>>> the committers have to officially decide whether to make these changes or
>>>> not.
>>>>
>>>> Note that in any case the changes will take affect *after* the 3.0
>>>> release.
>>>>
>>>> On behalf of the Lucene developers,
>>>> Michael Busch
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Draft for java-user mail about backwards-compatibility policy
changes
Posted by Mark Miller <ma...@gmail.com>.
For the record - I still don't see what we gain but confusion.
The major numbers don't have any significant meaning in terms of
features or advancements.
If we want to remove deprecations faster after deprecating in 4.1, we
should just not release 4.2,4.3,4.4,4.5, and then 4.9.
We should go from 4.1 to 4.9, or 4.1,4.2, then 4.9. We have always just
chosen how long we were stuck with stuff by how fast we decided to skip
the dots.
Mark Miller wrote:
> I think it should be more clear that the devs have not come to an
> agreement on this change yet, irregardless of the communities input.
>
> Michael McCandless wrote:
>
>> Looks good!
>>
>> Mike
>>
>> On Tue, Oct 13, 2009 at 3:07 PM, Michael Busch <bu...@gmail.com> wrote:
>>
>>
>>> Hi all,
>>>
>>> I wrote a draft for a mail I'd like to send to java-user to get some
>>> feedback about the proposed changes to our backwards-compatibility policy we
>>> discussed here and on LUCENE-1698.
>>> Let me know what you think please!
>>>
>>> Michael
>>>
>>>
>>> Hello Lucene users:
>>>
>>> In the past we have discussed our backwards-compatibility policy
>>> frequently on the Lucene developer mailinglist and we are very tempted
>>> to make some significant changes. In this mail I'd like to outline the
>>> proposed changes to get some feedback from the user community.
>>>
>>> Our current backwards-compatibility policy regarding API changes
>>> states that we can only make changes that break
>>> backwards-compatibility in major releases (3.0, 4.0, etc.); the next
>>> major release is the upcoming 3.0.
>>>
>>> Given how often we made major releases in the past in Lucene this
>>> means that deprecated APIs need to stay in Lucene for a very long
>>> time. E.g. if we deprecate an API in 3.1 we'll have to wait until 4.0
>>> before we can remove it. This means that the code gets very cluttered
>>> and adding new features gets somewhat more difficult, as attention has
>>> to be paid to properly support the old *and* new APIs for a quite long
>>> time.
>>>
>>> The current policy also leads to delaying a last minor release before
>>> a major release (e.g. 2.9), because the developers consider it as the
>>> last chance for a long time to introduce new APIs and deprecate old ones.
>>>
>>> The proposal now is to change this policy in a way, so that an API can
>>> only be removed if it was deprecated in at least one release, which
>>> can be a major *or* minor release. E.g. if we deprecate an API and
>>> release it with 3.1, we can remove it with the 3.2 release.
>>>
>>> For users this means of course that a simple jar drop-in replacement
>>> won't be possible anymore with almost every Lucene release (excluding
>>> bugfix releases, e.g. 2.9.0->2.9.1). However, you can be sure that if
>>> you're using a non-deprecated API it will be in the next release.
>>>
>>> Note that of course these proposed changes do not affect
>>> backwards-compatibility with old index formats. I.e. it will still be
>>> possible to read all 3.X indexes with any Lucene 4.X version.
>>>
>>> Our main goal is to find the right balance between
>>> backwards-compatibility support for all the Lucene users out there and
>>> fast and productive development of new features. If we get positive
>>> feedback here we will call a vote on the development mailinglist where
>>> the committers have to officially decide whether to make these changes or
>>> not.
>>>
>>> Note that in any case the changes will take affect *after* the 3.0
>>> release.
>>>
>>> On behalf of the Lucene developers,
>>> Michael Busch
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
>
>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Draft for java-user mail about backwards-compatibility policy
changes
Posted by Michael Busch <bu...@gmail.com>.
On 10/13/09 1:11 PM, Mark Miller wrote:
> I think it should be more clear that the devs have not come to an
> agreement on this change yet, irregardless of the communities input.
>
>
>
OK I made a few changes near the end to make that clearer. How's it now?
Draft:
Hello Lucene users:
In the past we have discussed our backwards-compatibility policy
frequently on the Lucene developer mailinglist and we are very tempted
to make some significant changes. In this mail I'd like to outline the
proposed changes to get some feedback from the user community.
Our current backwards-compatibility policy regarding API changes
states that we can only make changes that break
backwards-compatibility in major releases (3.0, 4.0, etc.); the next
major release is the upcoming 3.0.
Given how often we made major releases in the past in Lucene this
means that deprecated APIs need to stay in Lucene for a very long
time. E.g. if we deprecate an API in 3.1 we'll have to wait until 4.0
before we can remove it. This means that the code gets very cluttered
and adding new features gets somewhat more difficult, as attention has
to be paid to properly support the old *and* new APIs for a quite long
time.
The current policy also leads to delaying a last minor release before
a major release (e.g. 2.9), because the developers consider it as the
last chance for a long time to introduce new APIs and deprecate old ones.
The proposal now is to change this policy in a way, so that an API can
only be removed if it was deprecated in at least one release, which
can be a major *or* minor release. E.g. if we deprecate an API and
release it with 3.1, we can remove it with the 3.2 release.
For users this means of course that a simple jar drop-in replacement
won't be possible anymore with almost every Lucene release (excluding
bugfix releases, e.g. 2.9.0->2.9.1). However, you can be sure that if
you're using a non-deprecated API it will be in the next release.
Note that of course these proposed changes do not affect
backwards-compatibility with old index formats. I.e. it will still be
possible to read all 3.X indexes with any Lucene 4.X version.
Our main goal is to find the right balance between
backwards-compatibility support for all the Lucene users out there and
fast and productive development of new features.
The developers haven't come to an agreement on this proposal yet, hence
we'd like to ask the user community for feedback to help us make a
decision. After we gathered some feedback here we will call a vote on the
development mailinglist where the committers have to officially decide
whether to make these changes or not.
Note that in any case the changes will take affect *after* the 3.0
release.
On behalf of the Lucene developers,
Michael Busch
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Draft for java-user mail about backwards-compatibility policy
changes
Posted by Mark Miller <ma...@gmail.com>.
I think it should be more clear that the devs have not come to an
agreement on this change yet, irregardless of the communities input.
Michael McCandless wrote:
> Looks good!
>
> Mike
>
> On Tue, Oct 13, 2009 at 3:07 PM, Michael Busch <bu...@gmail.com> wrote:
>
>> Hi all,
>>
>> I wrote a draft for a mail I'd like to send to java-user to get some
>> feedback about the proposed changes to our backwards-compatibility policy we
>> discussed here and on LUCENE-1698.
>> Let me know what you think please!
>>
>> Michael
>>
>>
>> Hello Lucene users:
>>
>> In the past we have discussed our backwards-compatibility policy
>> frequently on the Lucene developer mailinglist and we are very tempted
>> to make some significant changes. In this mail I'd like to outline the
>> proposed changes to get some feedback from the user community.
>>
>> Our current backwards-compatibility policy regarding API changes
>> states that we can only make changes that break
>> backwards-compatibility in major releases (3.0, 4.0, etc.); the next
>> major release is the upcoming 3.0.
>>
>> Given how often we made major releases in the past in Lucene this
>> means that deprecated APIs need to stay in Lucene for a very long
>> time. E.g. if we deprecate an API in 3.1 we'll have to wait until 4.0
>> before we can remove it. This means that the code gets very cluttered
>> and adding new features gets somewhat more difficult, as attention has
>> to be paid to properly support the old *and* new APIs for a quite long
>> time.
>>
>> The current policy also leads to delaying a last minor release before
>> a major release (e.g. 2.9), because the developers consider it as the
>> last chance for a long time to introduce new APIs and deprecate old ones.
>>
>> The proposal now is to change this policy in a way, so that an API can
>> only be removed if it was deprecated in at least one release, which
>> can be a major *or* minor release. E.g. if we deprecate an API and
>> release it with 3.1, we can remove it with the 3.2 release.
>>
>> For users this means of course that a simple jar drop-in replacement
>> won't be possible anymore with almost every Lucene release (excluding
>> bugfix releases, e.g. 2.9.0->2.9.1). However, you can be sure that if
>> you're using a non-deprecated API it will be in the next release.
>>
>> Note that of course these proposed changes do not affect
>> backwards-compatibility with old index formats. I.e. it will still be
>> possible to read all 3.X indexes with any Lucene 4.X version.
>>
>> Our main goal is to find the right balance between
>> backwards-compatibility support for all the Lucene users out there and
>> fast and productive development of new features. If we get positive
>> feedback here we will call a vote on the development mailinglist where
>> the committers have to officially decide whether to make these changes or
>> not.
>>
>> Note that in any case the changes will take affect *after* the 3.0
>> release.
>>
>> On behalf of the Lucene developers,
>> Michael Busch
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org