World: r3wp

Graham, thanks for copying over those priorities from R2-Beta to 
here. About how those choices were made and phrased:


The R2-Beta world was used when we still thought of REBOL being updated 
more rarely, in larger increments. This is no longer the case, we 
are adopting the rapid release model, though more regulary than the 
R3 alphas. We need to shift our thinking accordingly.


Rapid release means that each individual R2 release doesn't have 
to include fixes for every outstanding bug. We can and will triage 
and prioritize, and your favorite bug may be moved to the next release. 
Which won't be a problem because that's coming next month, or the 
month after. Minor point releases will not be a major deal from now 
on, they will be monthly occurances.


The overall plan for the R2 2.7.x series is to fix what we can in 
R2 in a way that doesn't break things. This won't be a ground-up 
rewrite, as we are doing one of those already. No major model changes, 
just tweaks. There is a lot we can tweak though, including natives. 
We are trying to avoid disruptive changes that affect scripts at 
runtime, except in cases where things just didn't work before. Almost 
all code that works on 2.7.6 should continue to work - that is our 
goal. Don't expect broken code to stay broken though :)


The 2.7.7 release will not be ambitious, we just don't have the time. 
The priorities are business model changes and low-hanging fruit. 
The one piece of major breakage from the 2.7.x series that needs 
fixing in this release is the installer. If you have other priority 
fixes that can't wait til next month, and you are willing to do the 
work in this week, please speak up.

If people can get on the R2-Beta world and start discussing things 
by end of Tuesday pacific time, we can use that, otherwise all discussions 
will have to be here in this group. If that turns out to be the case, 
please keep the discussion on topic. During the next release period 
we can properly switch to the community development infrastructure 
we use to make R3. Yes, that includes R3 chat.

Brian, private msg.

One personal note: In Monday and Tuesday of this week (local time) 
I have a day job. Please accept my apologies for not being as active 
here during that time. By Tuesday evening I will be able to more 
actively participate in the development of 2.7.7, but for now I can 
only coordinate.

Where's your documentation about what is broken for the (windows) 
installer?

It's been broken for so long, I no longer have the computer where 
I originally wrote it back in 2000 and posted it to the mailing list. 
It's still in my head though, so I'll collect it by Tuesday evening 
and start working. In brief:

- I don't know about installation on platforms other than Windows. 
Someone else will have to chime in here. Too ambitious for 2.7.7.

- Windows 2000+ support is still broken. Multi-user support is broken 
(same thing, really).

- Folder usage was mostly fixed in 2.6.3, but the registry is still 
misused. Registry migration will be needed.

- Non-admin installation should be possible, including user-specific 
file associations.

- Installation was broken altogether in the 2.7.x series - it doesn't 
work at all, not even to 2.6.3 levels.

- No-install usage of View needs better support. This means UI support 
too, if need be. VIew should be able to be a portable app.

Keep in mind that portable app usage of directories is completely 
different than installed usage, and needs to be.

Fixing Windows 2000+ support will also enable Vista and Win7 - the 
rules are the same.

Should the R2-compatible mezzanine fixes from R2/Forward be integrated 
as well? The answer to that depends on the timeframe, Carl.

we have two days!

I don't see the installer being fixed in 2 days

The R2/forwards stuff is all tested ??

can you post a release so we can test it if not?

Yes, and the most recent release is already in R3 chat. The installer 
can be fixed in an evening at most.

for those of us not in R3 chat ...

...you'll be left out of 2.7.8 development. Get in there.

As for installer, me, as a fan of copy&run principle, I would like 
simple option as Altme client has - on first screen, please allow 
"run from current location", and never ask again ...

Pekr, that won't work with windows 7

... I expect that when you lauch .exe on system where REBOL is not 
yet installed, the installation process will run, right?

no?

That is the portable app method, which can't set file associations.

Nope ...

Hmm, installers, default dirs, etc., that's kind of deep topic :-)

Which I've already thought through. I've written installers for R2 
before and other apps.

To get altme to run from the my c:\altme directory, I either have 
to run as admin, or, I have to write enable myself on the directory

Right. That's why portable apps are usually run from USB keys with 
FAT filesystems.

In the long run I would prefer to make the installer configurable 
and encappable, but for now a View-specific one will do.

So, rebol has to go to <program files>\rebol ?  And it has to write 
in user documents somewhere?

Graham - exactly .... but - I hate that model ...

and when you start a rebol console .. you end up deep in user documents 
somewhere ...

there might be even 3 paths - rebol app (program files), rebol cache 
(user profile .... bla bla \roaming\rebol), rebol data user profile\documents\rebol 
...

Pekr, it's required for secure multi-user use on Windows. Hating 
it won't change that. No flame wars please - we don't have the time.

most of the time, I can guarantee you, that users feel lost, once 
they are supposed to navigate to their docs in file-manager ...

File placement is easy, and mostly handled by 2.6.3 - the real trick 
is registry usage.

BrianH - I am fine with whatever crap windows require. I have my 
most needed stuff on C:, in !mp3, !REBOL, !Foto etc. dirs. I run 
as an admin, so I don't care ...

So, if a program that is being installed needs Rebol ... where should 
it look?

Right. File placement is a matter of chosing the default folders 
of the installer, as it does now. You can change those choices.

Python seems to install to c:\python2n\

As in almost all cases, Python is a bad example.

BrianH: so where can users (not admin) safely put his rebol scripts, 
so that rebol executalbe can write and read from such a directory? 
We can't do it in program files, but can we do in somewhere on C:\REBOL?

The trick is registry usage. The folder locations can be looked up 
in the registry.at runtime, as long as those registry settings are 
in the right location of the registry. I'll have those exact locations 
Tuesday evening.

... or only user profile dirs is the right placement?

c:\rebol is out ... unless you write enable

d:\rebol is fine though :)

Pekr, it's not abot where the user can pt their user scripts, it's 
about the desktop files and such. File associations manage the user 
script issue.

User scripts can go wherever you like.

will the installer be written in rebol?

Or, will you use a standard installer script ?

It is already.

It's in the SDK source.

And how then will it cope with Windows 64?