Proposal for changing Lucene's backwards-compatibility policy

[Michael Busch]

Hello Lucene users:

In the past we have discussed our backwards-compatibility policy
frequently on the Lucene developer mailinglist and we are thinking about
making 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.

The obvious downside of this proposal is that a simple jar drop-in
replacement will not 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.
Potentionally giving up the drop-in replacement promise that Lucene
could make in the past is the main reason for the struggle the developers
are in and why 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.

So please tell us which you prefer as a back compatibility policy for
Lucene:
A) best effort drop-in back compatibility for minor version numbers
(e.g. v3.5 will be compatible with v3.2)
B) best effort drop-in back compatibility for the next minor version
number only, and deprecations may be removed after one minor release
(e.g. v3.3 will be compat with v3.2, but not v3.4)

Note that in any case the changes will take affect *after* the 3.0
release.

On behalf of the Lucene developers,
  Michael Busch

[Paul Elschot]

On Friday 16 October 2009 08:57:37 Michael Busch wrote:

> Hello Lucene users:
>
> In the past we have discussed our backwards-compatibility policy
> frequently on the Lucene developer mailinglist and we are thinking about
> making 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.
>
> The obvious downside of this proposal is that a simple jar drop-in
> replacement will not 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.
> Potentionally giving up the drop-in replacement promise that Lucene
> could make in the past is the main reason for the struggle the developers
> are in and why 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.
>
> So please tell us which you prefer as a back compatibility policy for
> Lucene:
> A) best effort drop-in back compatibility for minor version numbers
> (e.g. v3.5 will be compatible with v3.2)
> B) best effort drop-in back compatibility for the next minor version
> number only, and deprecations may be removed after one minor release
> (e.g. v3.3 will be compat with v3.2, but not v3.4)

I'd prefer B), with a minimum period of about two months to the
next release in case it removes deprecations.

Regards,
Paul Elschot

[Danil ŢORIN]

I'd vote A with following addition:

What about creating major version more often?

If there are incremental improvements which don't clutter the code too
much continue with 3.0 -> 3.1 -> 3.2 -> .. -> 3.X
Once there are significant changes which are hard to maintain backward
compatible start a 4.0 line.

Just as you did before, just lower the threshold on what kind of
changes force new major version release.

For example in 2.9 release cycle at least AttributeSource stuff
deserved a new major version.
Uwe's Trie/Numeric fields, LUCENE-1483 and so on are incremental so
could be minor releases.

So upcoming 3.0 with java 1.5 and massive deprecation of old stuff
would actually be at least 4.0.

On Fri, Oct 16, 2009 at 10:39, Paul Elschot <paul.elschot@...> wrote:

> On Friday 16 October 2009 08:57:37 Michael Busch wrote:
>> Hello Lucene users:
>>
>> In the past we have discussed our backwards-compatibility policy
>> frequently on the Lucene developer mailinglist and we are thinking about
>> making 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.
>>
>> The obvious downside of this proposal is that a simple jar drop-in
>> replacement will not 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.
>> Potentionally giving up the drop-in replacement promise that Lucene
>> could make in the past is the main reason for the struggle the developers
>> are in and why 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.
>>
>> So please tell us which you prefer as a back compatibility policy for
>> Lucene:
>> A) best effort drop-in back compatibility for minor version numbers
>> (e.g. v3.5 will be compatible with v3.2)
>> B) best effort drop-in back compatibility for the next minor version
>> number only, and deprecations may be removed after one minor release
>> (e.g. v3.3 will be compat with v3.2, but not v3.4)
>
> I'd prefer B), with a minimum period of about two months to the
> next release in case it removes deprecations.
>
> Regards,
> Paul Elschot
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[gabriele renzi-5]

On Fri, Oct 16, 2009 at 9:39 AM, Paul Elschot <paul.elschot@...> wrote:

> I'd prefer B), with a minimum period of about two months to the
> next release in case it removes deprecations.

for what my vote counts, seconded

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Christian Reuschling-2]

Hello Michael,

I also would prefer B - it also shortens the time to have a benefit of new
Lucene features in our applications.
It forces our lazy programmers (I am of course ;) ) to deal with them - and
reduces the efford to change to a major release afterwards.
Maybe some minimum time waiting before removing a deprecated API would be nice,
such as the 2 months Paul mentioned

regards

Chris



On Thu, 15 Oct 2009 23:57:37 -0700
Michael Busch <buschmic@...> wrote:

> Hello Lucene users:
>
> In the past we have discussed our backwards-compatibility policy
> frequently on the Lucene developer mailinglist and we are thinking about
> making 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.
>
> The obvious downside of this proposal is that a simple jar drop-in
> replacement will not 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.
> Potentionally giving up the drop-in replacement promise that Lucene
> could make in the past is the main reason for the struggle the developers
> are in and why 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.
>
> So please tell us which you prefer as a back compatibility policy for
> Lucene:
> A) best effort drop-in back compatibility for minor version numbers
> (e.g. v3.5 will be compatible with v3.2)
> B) best effort drop-in back compatibility for the next minor version
> number only, and deprecations may be removed after one minor release
> (e.g. v3.3 will be compat with v3.2, but not v3.4)
>
> Note that in any case the changes will take affect *after* the 3.0
> release.
>
> On behalf of the Lucene developers,
>   Michael Busch

[Jukka Zitting]

Hi,

On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN <torindan@...> wrote:
> What about creating major version more often?

+1 We're not going to run out of version numbers, so I don't see a
reason not to upgrade the major version number when making
backwards-incompatible changes.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Stefan Trcek]

On Friday 16 October 2009 08:57:37 Michael Busch wrote:
>
> So please tell us which you prefer as a back compatibility policy for
> Lucene:

I don't do drop in but recompile anyway, so it doesn't matter for me.
It is only important that the documentation is clear about what has to
be done.

> B) best effort drop-in back compatibility for the next minor version
> number only, and deprecations may be removed after one minor release
> (e.g. v3.3 will be compat with v3.2, but not v3.4)

Nevertheless I prefer B because the deprecation changes per release will
be smaller and maybe even grouped by topic. I prefer advancing step by
step. A bunch of deprecated API parts even hinders reading and
understanding the API. So, the sooner they are gone, the better.

Regards, Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[markrmiller]

Jukka Zitting wrote:

> Hi,
>
> On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN <torindan@...> wrote:
>  
>> What about creating major version more often?
>>    
>
> +1 We're not going to run out of version numbers, so I don't see a
> reason not to upgrade the major version number when making
> backwards-incompatible changes.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@...
> For additional commands, e-mail: java-user-help@...
>
>  

For what its worth, I agree with you guys. Less confusion in upgrading :)

--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Uwe Schindler]

> > So please tell us which you prefer as a back compatibility policy for
> > Lucene:
>
> I don't do drop in but recompile anyway, so it doesn't matter for me.
> It is only important that the documentation is clear about what has to
> be done.
>
> > B) best effort drop-in back compatibility for the next minor version
> > number only, and deprecations may be removed after one minor release
> > (e.g. v3.3 will be compat with v3.2, but not v3.4)
>
> Nevertheless I prefer B because the deprecation changes per release will
> be smaller and maybe even grouped by topic. I prefer advancing step by
> step. A bunch of deprecated API parts even hinders reading and
> understanding the API. So, the sooner they are gone, the better.

+1 Even for me as a core developer, it's always a pain to find out: Is it
TopDocsCollector, TopFieldDocCollector and other, which are the right one.
The names of these classes in 2.9 and the mix between deprecated and not
deprecated is a hell!

In my opinion, we should more often release major releases. And this always
using a short-time x.9 -> (x+1).0. So new API in .9 and then 2 month later
release the major release.

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Erdinc Yilmazel-2]

I'd go with B. I never do drop-in replacement of a jar even if it is a minor
release for any library. I always recompile. I think the major version
number shouldn't be changed unless there are lots of API changes or changes
in the index format.


On Fri, Oct 16, 2009 at 12:38 PM, Mark Miller <markrmiller@...> wrote:

> Jukka Zitting wrote:
> > Hi,
> >
> > On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN <torindan@...>
> wrote:
> >
> >> What about creating major version more often?
> >>
> >
> > +1 We're not going to run out of version numbers, so I don't see a
> > reason not to upgrade the major version number when making
> > backwards-incompatible changes.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@...
> > For additional commands, e-mail: java-user-help@...
> >
> >
> For what its worth, I agree with you guys. Less confusion in upgrading :)
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@...
> For additional commands, e-mail: java-user-help@...
>
>

[Yonik Seeley-2]

On Fri, Oct 16, 2009 at 4:54 AM, Jukka Zitting <jukka.zitting@...> wrote:
> Hi,
>
> On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN <torindan@...> wrote:
>> What about creating major version more often?
>
> +1 We're not going to run out of version numbers, so I don't see a
> reason not to upgrade the major version number when making
> backwards-incompatible changes.

+1
(Option A).

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Steven A Rowe]

On 10/16/2009 at 2:58 AM, Michael Busch wrote:
> B) best effort drop-in back compatibility for the next minor version
> number only, and deprecations may be removed after one minor release
> (e.g. v3.3 will be compat with v3.2, but not v3.4)

This is only true on a per-feature basis.  For example, if feature A is deprecated in v3.1, and feature B is deprecated in v3.2, then v3.3 will be "compat" with v3.2 only as far as feature B is concerned; feature A will no longer be present in v3.3.

Under these circumstances, saying "v3.3 will be compat with v3.2" with no caveats sounds to me like false advertising.

Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[markrmiller]

Steven A Rowe wrote:

> On 10/16/2009 at 2:58 AM, Michael Busch wrote:
>  
>> B) best effort drop-in back compatibility for the next minor version
>> number only, and deprecations may be removed after one minor release
>> (e.g. v3.3 will be compat with v3.2, but not v3.4)
>>    
>
> This is only true on a per-feature basis.  For example, if feature A is deprecated in v3.1, and feature B is deprecated in v3.2, then v3.3 will be "compat" with v3.2 only as far as feature B is concerned; feature A will no longer be present in v3.3.
>
> Under these circumstances, saying "v3.3 will be compat with v3.2" with no caveats sounds to me like false advertising.
>
> Steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@...
> For additional commands, e-mail: java-user-help@...
>
>  

Right - confusing. And even if we peg deprecation removal to only given
point releases to address this, its still confusing as to which.
Solution? Major numbers :) If deprecations need to be removed faster,
instead of 4 or 5 releases within a major number, 2 or 3 could be done.

Its also a real pain for someone to skip a few releases and then upgrade
- right now you just hit the 2.9 release and get all the dep warnings to
help you go to 3.0. With this, if your late to the party, you will lose
all the dep warnings - you will have to update to every other release to
catch up.

--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Michael Busch]

On 10/16/09 10:27 AM, Steven A Rowe wrote:

> On 10/16/2009 at 2:58 AM, Michael Busch wrote:
>    
>> B) best effort drop-in back compatibility for the next minor version
>> number only, and deprecations may be removed after one minor release
>> (e.g. v3.3 will be compat with v3.2, but not v3.4)
>>      
> This is only true on a per-feature basis.  For example, if feature A is deprecated in v3.1, and feature B is deprecated in v3.2, then v3.3 will be "compat" with v3.2 only as far as feature B is concerned; feature A will no longer be present in v3.3.
>
> Under these circumstances, saying "v3.3 will be compat with v3.2" with no caveats sounds to me like false advertising.
>
> Steve
>
>    

That is true. Further above in my mail I said "simple jar drop-in
replacement will not be possible anymore with almost every Lucene
release"and I should have made it clearer in the sentence you pointed
out too: with option B you can only be sure that you can switch to a new
version (e.g. v3.3) without the need to recompile if your app compiled
against the previous version (v3.2) without deprecation warnings.

Let me point out that in any case, no matter if we pick A or B, the
committers will try what they can to make upgrading as easy as possible.
If you look back in Lucene's history I think we always did that,
especially with index file format (I don't think we ever required
reindexing to upgrade). Now in terms of API backwards-compatibility even
with option B it doesn't mean we'll go crazy with deprecations and
removals. We don't *have* to remove an API in 3.3 only because it was
deprecated in 3.2.

Let me give you another example: the current TokenStream API changes
were very big, and the TokenStream API is very central and often
extended by users. Now with the current backwards-compatibility policy
we decided to remove the old API entirely in 3.0. If we had policy B in
place already, we'd be able wait until 3.1 and give users more
transition time. But we certainly don't want to wait until 4.0 - it may
be surprising for many how much (complicated) code is currently in
Lucene to support compatibility for this and other features.

Even if we try to make major releases more often, how often do people
realistically expect this will happen? Lucene 2.0 was released in May
2006. The 2.9 release that is now available still supports every single
public and protected API from the last 3 1/2 years. We're saying for
about 2 years now that we should make releases more often in general.
The committers always vote +1 if someone says "let's release more
often". But if didn't happen so far. We could now analyze the reasons
and how we could change that. But frankly I think partially it's just
the nature of things: there are many different people, with different
schedules, working on different features of different sizes and Lucene
has different components. Getting all this aligned isn't so easy. Why
will just saying once again "Hey, let's just release more often" work
now if it hasn't in the last two years?

  Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[markrmiller]

Michael Busch wrote:
>  Why will just saying once again "Hey, let's just release more often"
> work now if it hasn't in the last two years?
>
>  Mich

I don't know that we need to release more often to take advantage of
major numbers. 2.2 was released in 07 - we could have just released 2.9
right after 2.2 rather than also releasing 2.3 and 2.4. The number of
releases between major releases is self imposed.

--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[markrmiller]

Mark Miller wrote:

> Michael Busch wrote:
>  
>>  Why will just saying once again "Hey, let's just release more often"
>> work now if it hasn't in the last two years?
>>
>>  Mich
>>    
>
> I don't know that we need to release more often to take advantage of
> major numbers. 2.2 was released in 07 - we could have just released 2.9
> right after 2.2 rather than also releasing 2.3 and 2.4. The number of
> releases between major releases is self imposed.
>
>  

And actually - even 2.9, which took so long, didn't have to. A .9
release could be very fast and only done as a stepping stone to the next
major release. The pain of how long everything took was just self
imposed. We could have moved to 3.0 years ago easily if someone has
suggested so. The truth is, all the deprecation complain stuff only
recently reached a boil - so noone suggested moving to the next major
version faster long enough ago. When they did, we jumped from 2.4 to
2.9. And the 2.9 was a huge release - but again, it didn't have to be.
It could have been a formality - Grant was arguing at one point that it
should have been.

--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Luis Alves-4]

gabriele renzi wrote:
> On Fri, Oct 16, 2009 at 9:39 AM, Paul Elschot <paul.elschot@...> wrote:
>
>  
>> I'd prefer B), with a minimum period of about two months to the
>> next release in case it removes deprecations.
>>    
+1 for B)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Luis Alves-4]

Mark Miller wrote:

> Mark Miller wrote:
>  
>> Michael Busch wrote:
>>  
>>    
>>>  Why will just saying once again "Hey, let's just release more often"
>>> work now if it hasn't in the last two years?
>>>
>>>  Mich
>>>    
>>>      
>> I don't know that we need to release more often to take advantage of
>> major numbers. 2.2 was released in 07 - we could have just released 2.9
>> right after 2.2 rather than also releasing 2.3 and 2.4. The number of
>> releases between major releases is self imposed.
>>
>>  
>>    
> And actually - even 2.9, which took so long, didn't have to. A .9
> release could be very fast and only done as a stepping stone to the next
> major release. The pain of how long everything took was just self
> imposed. We could have moved to 3.0 years ago easily if someone has
> suggested so. The truth is, all the deprecation complain stuff only
> recently reached a boil - so noone suggested moving to the next major
> version faster long enough ago. When they did, we jumped from 2.4 to
> 2.9. And the 2.9 was a huge release - but again, it didn't have to be.
> It could have been a formality - Grant was arguing at one point that it
> should have been.
>
>  

I don't see much difference in have frequent major releases or frequent
minor releases,
if they share same backwards-compatibility policy.

If you have 4 major releases per year 4.0 , 5.0, 6.0 and 7.0, or four
minor release
3.2, 3.3, 3.4, 3.5.
 From the user perspective is not going to help that much since, since
moving from 4.0 to 6.0
will have the same cost of moving from 3.2 to 3.4, if the
backwards-compatibility is similar in
major releases and minor-releases and the time between release is the same.

What I like in Michael proposal is that it gives the user a chance to
move between sequential minor releases
without breaking the code, if you follow the process of cleaning your
code from deprecated calls.
I would hope this rule would also apply to 3.9 to 4.0 if these are
sequential releases.

If you see what lucene community is doing with 2.4->2.9->3.0 this is
actually Michael proposal
but now will be the rule instead of the exception that was done just for
3.0 major release.

Lucene could have gone from 2.4 to 3.0, without having any releases in
between, since it was a major
release and there was no need to be backward-compatible, but that would
have created major code migration
headaches.

Option B) allows developers to remove old code more quickly and does not
force the lucene community to create
major releases for code clean up. It gives flexibility and guarantees
the users with a clean upgrade path.

I also propose that we should also apply this rule between the last
minor release of previous major release
and next major release, just as it was done for 2.4->2.9->3.0.



---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[markrmiller]

Luis Alves wrote:

> Mark Miller wrote:
>> Mark Miller wrote:
>>  
>>> Michael Busch wrote:
>>>      
>>>>  Why will just saying once again "Hey, let's just release more often"
>>>> work now if it hasn't in the last two years?
>>>>
>>>>  Mich
>>>>          
>>> I don't know that we need to release more often to take advantage of
>>> major numbers. 2.2 was released in 07 - we could have just released 2.9
>>> right after 2.2 rather than also releasing 2.3 and 2.4. The number of
>>> releases between major releases is self imposed.
>>>
>>>      
>> And actually - even 2.9, which took so long, didn't have to. A .9
>> release could be very fast and only done as a stepping stone to the next
>> major release. The pain of how long everything took was just self
>> imposed. We could have moved to 3.0 years ago easily if someone has
>> suggested so. The truth is, all the deprecation complain stuff only
>> recently reached a boil - so noone suggested moving to the next major
>> version faster long enough ago. When they did, we jumped from 2.4 to
>> 2.9. And the 2.9 was a huge release - but again, it didn't have to be.
>> It could have been a formality - Grant was arguing at one point that it
>> should have been.
>>
>>  
> I don't see much difference in have frequent major releases or
> frequent minor releases,
> if they share same backwards-compatibility policy.
>
> If you have 4 major releases per year 4.0 , 5.0, 6.0 and 7.0, or four
> minor release
> 3.2, 3.3, 3.4, 3.5.
> From the user perspective is not going to help that much since, since
> moving from 4.0 to 6.0
> will have the same cost of moving from 3.2 to 3.4, if the
> backwards-compatibility is similar in
> major releases and minor-releases and the time between release is the
> same.
>
> What I like in Michael proposal is that it gives the user a chance to
> move between sequential minor releases
> without breaking the code, if you follow the process of cleaning your
> code from deprecated calls.
> I would hope this rule would also apply to 3.9 to 4.0 if these are
> sequential releases.

This is already the case. Except it easier to follow because you know it
happens on the .9 to .0 release.
>
> If you see what lucene community is doing with 2.4->2.9->3.0 this is
> actually Michael proposal
> but now will be the rule instead of the exception that was done just
> for 3.0 major release.
No - its a rule now. Its happens every time we go from .9 -> .0
>
> Lucene could have gone from 2.4 to 3.0, without having any releases in
> between, since it was a major
> release and there was no need to be backward-compatible, but that
> would have created major code migration
> headaches.
No it couldn't have. Thats would have been against the current back
compat policy. There isn't much difference between the two options -
except that one is clearer about the when and where - it happens on the
.9 -> .0 move - with the this proposed way, it happens on some minor
release -
to know which, you have to follow along. And possibly different
deprecations would be removed on different minor releases - making the
whole thing a
mess of a lot harder than using major number points.
>
> Option B) allows developers to remove old code more quickly and does
> not force the lucene community to create
> major releases for code clean up. It gives flexibility and guarantees
> the users with a clean upgrade path.
Thats the only reason we create major releases now. It has nothing to do
with features. So doing it more often doesn't hurt anything.
>
> I also propose that we should also apply this rule between the last
> minor release of previous major release
> and next major release, just as it was done for 2.4->2.9->3.0.
That rule already exists.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@...
> For additional commands, e-mail: java-user-help@...
>


--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...

[Luis Alves-4]

Mark Miller wrote:

> Luis Alves wrote:
>  
>> Mark Miller wrote:
>>    
>>> Mark Miller wrote:
>>>  
>>>      
>>>> Michael Busch wrote:
>>>>      
>>>>        
>>>>>  Why will just saying once again "Hey, let's just release more often"
>>>>> work now if it hasn't in the last two years?
>>>>>
>>>>>  Mich
>>>>>          
>>>>>          
>>>> I don't know that we need to release more often to take advantage of
>>>> major numbers. 2.2 was released in 07 - we could have just released 2.9
>>>> right after 2.2 rather than also releasing 2.3 and 2.4. The number of
>>>> releases between major releases is self imposed.
>>>>
>>>>      
>>>>        
>>> And actually - even 2.9, which took so long, didn't have to. A .9
>>> release could be very fast and only done as a stepping stone to the next
>>> major release. The pain of how long everything took was just self
>>> imposed. We could have moved to 3.0 years ago easily if someone has
>>> suggested so. The truth is, all the deprecation complain stuff only
>>> recently reached a boil - so noone suggested moving to the next major
>>> version faster long enough ago. When they did, we jumped from 2.4 to
>>> 2.9. And the 2.9 was a huge release - but again, it didn't have to be.
>>> It could have been a formality - Grant was arguing at one point that it
>>> should have been.
>>>
>>>  
>>>      
>> I don't see much difference in have frequent major releases or
>> frequent minor releases,
>> if they share same backwards-compatibility policy.
>>
>> If you have 4 major releases per year 4.0 , 5.0, 6.0 and 7.0, or four
>> minor release
>> 3.2, 3.3, 3.4, 3.5.
>> From the user perspective is not going to help that much since, since
>> moving from 4.0 to 6.0
>> will have the same cost of moving from 3.2 to 3.4, if the
>> backwards-compatibility is similar in
>> major releases and minor-releases and the time between release is the
>> same.
>>
>> What I like in Michael proposal is that it gives the user a chance to
>> move between sequential minor releases
>> without breaking the code, if you follow the process of cleaning your
>> code from deprecated calls.
>> I would hope this rule would also apply to 3.9 to 4.0 if these are
>> sequential releases.
>>    
> This is already the case. Except it easier to follow because you know it
> happens on the .9 to .0 release.
>  
>> If you see what lucene community is doing with 2.4->2.9->3.0 this is
>> actually Michael proposal
>> but now will be the rule instead of the exception that was done just
>> for 3.0 major release.
>>    
> No - its a rule now. Its happens every time we go from .9 -> .0
>  
>> Lucene could have gone from 2.4 to 3.0, without having any releases in
>> between, since it was a major
>> release and there was no need to be backward-compatible, but that
>> would have created major code migration
>> headaches.
>>    
> No it couldn't have. Thats would have been against the current back
> compat policy. There isn't much difference between the two options -
> except that one is clearer about the when and where - it happens on the
> .9 -> .0 move - with the this proposed way, it happens on some minor
> release -
> to know which, you have to follow along. And possibly different
> deprecations would be removed on different minor releases - making the
> whole thing a
> mess of a lot harder than using major number points.
>  
>> Option B) allows developers to remove old code more quickly and does
>> not force the lucene community to create
>> major releases for code clean up. It gives flexibility and guarantees
>> the users with a clean upgrade path.
>>    
> Thats the only reason we create major releases now. It has nothing to do
> with features. So doing it more often doesn't hurt anything.
>  
>> I also propose that we should also apply this rule between the last
>> minor release of previous major release
>> and next major release, just as it was done for 2.4->2.9->3.0.
>>    
> That rule already exists.
>  
>>
>>    

Thanks for the reply,

If that is the case, and major releases become more frequent maybe
every 6-12 months. I don't see many differences.

But there needs to be some forced push for these shorter major release
cycles,
to allow for code clean cycles to also be sorter.

Is there any ideas how to push the community,
to make major release cycles shorter?



---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@...
For additional commands, e-mail: java-user-help@...