Leo 6.4 b3 and 6.4 final coming soon

[Edward K. Ream]

I plan to release b3 this Friday, regardless of outstanding Leo bugs. It's time to work on release issues.

I plan to release Leo 6.4 final about one week later, regardless of the status of leoInteg.

Neither leoserver.py nor leoInteg must be perfect to release 6.4 final. The only constraint on Leo is that future versions of leoserver.py be upward compatible with the leoserver.py contained in 6.4 final. That constraint should be easy to satisfy.

Félix, does this seem like a reasonable plan?

Edward

[Félix]

Hi Edward,

 I'm not sure what to do next in the short term : I cant reproduce what  Alexey / Gaurami reported : the text selection range bug...!

(BTW leointeg does not copy text, it only sends the start/end numeric row+col positions of the first selection range (start-end) in a document)

I've updated the required engine to vscode 1.60 as it's got the fix I requested (and many other small fixes) ...Could that have fixed the bug ? 

Could it be that alexei changed the line ending to crlf instead of just lf at the bottom right corner of vscode window while editing a leo body and it shifted the row/col relative number(s)? 

Last night I spent an hour or so trying to provoke the bug under my linux machine - and tonight i tried on my windows partition thinking long @clean files in windows would have a different line ending that would account for the shift in position when Leo converts to a position in the body string... But I cant seem to be able to  reproduce the bug... God how I'd wish to physically teleport beside Alexey to really see what he's doing to get this bug... :/ (surely something else is in play... And his - although good - description is missing something crucial)

So , I'm using leoInteg relatively bug-free for long sessions wondering why the heck dont I just release this version I've got going as 1.0 instead of 0.1.19 beta ...?

I guess whichever  bug (re)surfaces in the short term (that i could reproduce) I can just work on it when it does, and automatically push a 1.1 version when fixed on each user's install through the microsoft extension system.

IN CONCLUSION

So here's what I'll do: I'll release 0.1.19 right now tonight - and I'll release 1.0 (without changes if nothing pops up) along you with 6.4 so they're released the same day.  (I'll keep the issue open on github about the selections range.)

My hope is that the new vscode 1.60 - along with the latest leointeg 0.1.19 is somewhat "acceptable/bug free" as a "1.0 version". 

--

Félix

[Edward K. Ream]

On Mon, Sep 13, 2021 at 8:43 PM Félix <felix...@gmail.com> wrote:

I'm not sure what to do next in the short term : I cant reproduce what  Alexey / Gaurami reported : the text selection range bug...!

...

So , I'm using leoInteg relatively bug-free for long sessions wondering why the heck dont I just release this version I've got going as 1.0 instead of 0.1.19 beta ...?

I'm still working on a few bugs for Leo 6.4 b3, so releasing 0.1.19 beta seems reasonable.

So here's what I'll do: I'll release 0.1.19 right now tonight - and I'll release 1.0 (without changes if nothing pops up) along you with 6.4 so they're released the same day.  (I'll keep the issue open on github about the selections range.)

I agree with this plan. It's time to get the code out the door!

I am dealing with my own difficult-to-pin-down bug. I'll do my best in the next few days, but I'm not going to delay either Leo b3 or final for the bug.

One thought about compatibility. Perhaps the client could ask the server for the server version, say a version tuple like (1, 0, 0). This would allow clients to warn if some features depend on later versions of the server.

For example, suppose the 'extract' bug ends up requiring leoserver 1.1. The client could warn if the leoserver is 1.0 and degrade gracefully.

Right now the server defines a __version__ constant. Perhaps this should be composed from the version tuple.

Summary

Thanks for your work trying to track down the extract bug. Imo, this bug isn't remotely serious enough to delay leoInteg 1.0.

Imo, the server should be able to report the version tuple, but right now I see no need for the client to do anything with the version.

What do you think?

Edward

[Edward K. Ream]

On Tue, Sep 14, 2021 at 9:22 AM Edward K. Ream <edre...@gmail.com> wrote:

> Perhaps the client could ask the server for the server version, say a version tuple like (1, 0, 0). This would allow clients to warn if some features depend on later versions of the server.

I'll update leoserver.py so it defines __version__ in terms of the version tuple.

Félix, if it's alright with you I'll delegate to you the task of having the server respond to a query about the version.

Edward

[Edward K. Ream]

On Tue, Sep 14, 2021 at 9:26 AM Edward K. Ream <edre...@gmail.com> wrote:

> I'll update leoserver.py so it defines __version__ in terms of the version tuple.

Done in devel at 97db83.

Edward