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
gabriele renzi wrote:
On Fri, Oct 16, 2009 at 9:39 AM, Paul Elschot paul.elsc...@xs4all.nl 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)
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
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
On Tue, Oct 27, 2009 at 9:07 PM, Luis Alves lafa...@gmail.com 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.
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
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
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 Fri, Oct 16, 2009 at 9:39 AM, Paul Elschot paul.elsc...@xs4all.nl 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
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
Hi,
On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN torin...@gmail.com 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
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
Jukka Zitting wrote:
Hi,
On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN torin...@gmail.com 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
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
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
On Fri, Oct 16, 2009 at 4:54 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Fri, Oct 16, 2009 at 10:23 AM, Danil ŢORIN torin...@gmail.com 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
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
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
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
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
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
21 matches
Mail list logo
