My vote is for option A. It's generally implied that a major version brings
in major changes (api as well as others), while the minor is, well, minor.
Why should that be broken for lucene? It would become increasingly difficult
for the lucene user community to catch up if they skipped one or two mi
On Tue, Oct 27, 2009 at 9:07 PM, Luis Alves wrote:
> But there needs to be some forced push for these shorter major release
> cycles,
> to allow for code clean cycles to also be sorter.
Maybe... or maybe not.
There's also value in a more stable API over a longer period of time.
Different people w
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
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
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 wa
gabriele renzi wrote:
On Fri, Oct 16, 2009 at 9:39 AM, 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-m
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 0
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 a
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 i
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 t
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,
On Fri, Oct 16, 2009 at 4:54 AM, Jukka Zitting wrote:
> Hi,
>
> On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN 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
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 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 t
Jukka Zitting wrote:
> Hi,
>
> On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN 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-incompat
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) b
Hi,
On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN 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
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 bef
On Fri, Oct 16, 2009 at 9:39 AM, 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:
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
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
> pr
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 c
22 matches
Mail list logo