planning release, Re: updating license headers - what's next?

[Vadim Gritsenko <va...@reverycodes.com>]

Natalia Shilenkova wrote:
> Speaking of next version... Are there any plans for new release?

There were no special plans, but we should make some.

> It
> certainly has been a while since last release. Is there anything
> outstanding?

I see that there is an indexing related patch from you in bugzilla. So that 
would make at least one outstanding issue :)

There are also other loose ends - like document caching, meta data handling, etc 
- which is good to have fixed before release. On the other hand, there is always 
something to fix and that should not delay release indefinitely.

Bigger question, IMHO, is what should we label the next release - should it be 
next beta, b5, or should we label it as final 1.1 release? Any opinions?

Vadim

Re: planning release, Re: updating license headers - what's next?

[Vadim Gritsenko <va...@reverycodes.com>]

Natalia Shilenkova wrote:
> Any idea when the release thing may happen? I have at least a couple
> of patches in progress, would like to get them included before
> release.

I think release should happen sometime after we decide on some release plan ;-)

I'll try to draft one soon...

Vadim

> Natalia
> 
> On 3/7/07, Vadim Gritsenko <va...@reverycodes.com> wrote:
>> But release 1.1 must happen with Java 1.3, there is no any other way. 
>> After 1.1
>> is out, we can discuss minimum Java version. I'd suggest making a poll 
>> on both
>> dev and user lists, and then go with results of the poll.
>>
>> Vadim

Re: planning release, Re: updating license headers - what's next?

[Natalia Shilenkova <ns...@gmail.com>]

Any idea when the release thing may happen? I have at least a couple
of patches in progress, would like to get them included before
release.

Natalia

On 3/7/07, Vadim Gritsenko <va...@reverycodes.com> wrote:
> But release 1.1 must happen with Java 1.3, there is no any other way. After 1.1
> is out, we can discuss minimum Java version. I'd suggest making a poll on both
> dev and user lists, and then go with results of the poll.
>
> Vadim
>

Re: planning release, Re: updating license headers - what's next?

[Todd Byrne <to...@gmail.com>]

Sounds good.

Todd

On 3/7/07, Vadim Gritsenko <va...@reverycodes.com> wrote:
>
> Todd Byrne wrote:
> > Shouldn't we go for broke and move to 1.5 ? 1.5 has a bunch of language
> > features that very nice, and has been out sense 2004-09-29
>
> That is tempting... :)
>
> But release 1.1 must happen with Java 1.3, there is no any other way.
> After 1.1
> is out, we can discuss minimum Java version. I'd suggest making a poll on
> both
> dev and user lists, and then go with results of the poll.
>
> Vadim
>

Re: planning release, Re: updating license headers - what's next?

[Vadim Gritsenko <va...@reverycodes.com>]

Todd Byrne wrote:
> Shouldn't we go for broke and move to 1.5 ? 1.5 has a bunch of language 
> features that very nice, and has been out sense 2004-09-29

That is tempting... :)

But release 1.1 must happen with Java 1.3, there is no any other way. After 1.1 
is out, we can discuss minimum Java version. I'd suggest making a poll on both 
dev and user lists, and then go with results of the poll.

Vadim

Re: planning release, Re: updating license headers - what's next?

[Todd Byrne <to...@gmail.com>]

Shouldn't we go for broke and move to 1.5 ? 1.5 has a bunch of language
features that very nice, and has been out sense 2004-09-29

Todd

On 3/6/07, Vadim Gritsenko <va...@reverycodes.com> wrote:
>
> Georg Sauer-Limbach wrote:
> >
> >>> Speaking of next version... Are there any plans for new release?...
> >> There are also other loose ends - like document caching, meta data
> >> handling, etc - which is good to have fixed before release.
> >
> > There is the problem that changes to the database that are made
> > via the local interface (command line) are not reflected in a
> > running server instance, i.e. in Tomcat. Maybe this makes a
> > candidate for nice-to-fix?
>
> No, this one does not. But bring in other suggestions :)
>
> Regarding your problem. You should never attempt to open database files
> from two
> processes, such as Tomcat & command line tool with -l switch, since that
> will
> corrupt your database. If you are running instance of db in Tomcat, use db
> URL
> in the command line to access this running instance, instead of -l switch
> [1]:
>
>    ./bin/xindice lc -c xmldb:xindice://localhost:8080/db
>
> BTW, have you tried the latest trunk? If you are using windows it should
> prevent
> you from concurrently accessing same database files from different
> processes. It
> does not work for me in OS X though... When Xindice drops minimum java 1.3
> requirement, we could use java 1.4's new file I/O to make file locking
> work on
> all platforms.
>
> Regards,
> Vadim
>
> [1] http://wiki.apache.org/xindice/XindiceFAQ/XindicePort
>

Re: planning release, Re: updating license headers - what's next?

[Georg Sauer-Limbach <gs...@gslweb.de>]

Vadim Gritsenko wrote:
> Georg Sauer-Limbach wrote:
>> There is the problem that changes to the database that are made
>> via the local interface (command line) are not reflected in a
>> running server instance, i.e. in Tomcat. Maybe this makes a
>> candidate for nice-to-fix?
> No, this one does not. But bring in other suggestions :)
>
> Regarding your problem. You should never attempt to open database 
> files from two processes, such as Tomcat & command line tool with -l 
> switch, since that will corrupt your database. If you are running 
> instance of db in Tomcat, use db URL in the command line to access 
> this running instance, instead of -l switch [1]:
>
>   ./bin/xindice lc -c xmldb:xindice://localhost:8080/db
>
Thanks for the hint, I really should avoid the local calls.
I really used them only for the less typing :-)
> BTW, have you tried the latest trunk? If you are using windows it 
> should prevent you from concurrently accessing same database files 
> from different processes. It does not work for me in OS X though... 
> When Xindice drops minimum java 1.3 requirement, we could use java 
> 1.4's new file I/O to make file locking work on all platforms.
We are still using version 1.4b, and on Unix. It would certainly be
good to have the locking functionality on all systems. But I
understand it is difficult with Java 1.3.

Regards
Georg

Re: planning release, Re: updating license headers - what's next?

[Vadim Gritsenko <va...@reverycodes.com>]

Georg Sauer-Limbach wrote:
> 
>>> Speaking of next version... Are there any plans for new release?...
>> There are also other loose ends - like document caching, meta data 
>> handling, etc - which is good to have fixed before release.
> 
> There is the problem that changes to the database that are made
> via the local interface (command line) are not reflected in a
> running server instance, i.e. in Tomcat. Maybe this makes a
> candidate for nice-to-fix?

No, this one does not. But bring in other suggestions :)

Regarding your problem. You should never attempt to open database files from two 
processes, such as Tomcat & command line tool with -l switch, since that will 
corrupt your database. If you are running instance of db in Tomcat, use db URL 
in the command line to access this running instance, instead of -l switch [1]:

   ./bin/xindice lc -c xmldb:xindice://localhost:8080/db

BTW, have you tried the latest trunk? If you are using windows it should prevent 
you from concurrently accessing same database files from different processes. It 
does not work for me in OS X though... When Xindice drops minimum java 1.3 
requirement, we could use java 1.4's new file I/O to make file locking work on 
all platforms.

Regards,
Vadim

[1] http://wiki.apache.org/xindice/XindiceFAQ/XindicePort

Re: planning release, Re: updating license headers - what's next?

[Georg Sauer-Limbach <gs...@gslweb.de>]

>> Speaking of next version... Are there any plans for new release?...
> There are also other loose ends - like document caching, meta data 
> handling, etc - which is good to have fixed before release.

There is the problem that changes to the database that are made
via the local interface (command line) are not reflected in a
running server instance, i.e. in Tomcat. Maybe this makes a
candidate for nice-to-fix?

Georg