My vision for Beta/One is a running in-web tutorial that is unleashed to the world. This will teach the language, show off features, and be able to automate some browser functionality.
I’m not sure exactly what it would be able to automate. A good first step along the way will be a turtle-graphics style “pen up, pen down” kind of thing, but I don’t know if that will be the most compelling demo. Consider drawing to be the worst-case scenario domain…and something more useful like PARSE-based RegExr to be a shoot-the-moon kind of target.
Expecting this before the end of the year would be naive. But I’m hoping not to miss January by much.
- We may not have UTF-8 Everywhere merged in by then, but its effects are already accounted for in the API…and I’m confident it’s the right answer.
- The debugger might not be fantastic, but stepwise debugging should work.
- I’ll have all the Rebmu puzzles updated and running, so Rebmu will be one of the things you can do in the browser version.
Should there be a release earlier than that?
If a version of the code works for someone for some purpose, then they may take that build and use it as-is for as long as they like. This is how R3-Alpha and Rebol2 worked, after all…it froze on one day and then that’s what you had with no support thereafter. That’s always an option.
And if you report a bug that gets a patch to the mainline, you can apply that patch and rebuild your executable. That is fine.
But I can’t promise to commit bugfixes to your version and the master, and worry about how to build the releases, etc. I realize this may not fit everyone’s wishful timelines. But I’m sorry, I don’t have the bandwidth for anything else.
A Rebol by any other name…
In addition to combining the browser release with the stable release is that Beta One will be when to decide whether or not to keep calling the project Rebol. This decision will be made by essentially offering Carl a time-boxed proposal: the GitHub
rebol/rebol repo gets the current code of the “Ren-C library” with a voting structure that can outvote any one person (including Carl or me), the community gets control of rebol.org and rebol.net and have the ability to launch documentation and a module repository there, and he keeps rebol.com for whatever he feels like. He may join in development or not, as he wishes.
If the time-box is not met, we very simply adopt a new project name, and stop mentioning “Rebol”. Resources we control (such as this forum) will move under the new name. Resources we don’t control will be forked as licensing permits, which it generally does.
Why haven’t we done this yet? Firstly, because I don’t think it’s fair to be pressuring about a project that hasn’t completely proven itself, see my remarks about R3-Alpha parity. Plus, it would be premature to make some “big announcement” about a newly-named project that still has major decisions to work out. You don’t get a second chance to make a first announcement. Note just how drastic the null change was. We do not want to drop something like that on normal users after they’ve painstakingly written a bunch of code.
Existing Rebol users are different. They are used to being the guinea pigs and having the rug yanked out from under them (hopefully a mixed metaphor :P) But people who’ve been using the language for decades are worn out, and I think that’s why I’ve really not been counting on old-school Rebol users as being the target audience for any “products”.
In a sense, keeping the Rebol name is probably more a liability than anything else. Certainly Red used to see association in that way…and wanted to distance itself from the somewhat spotty track record, and “weird” community reputation. The reason to do it is to aim for holding up the standard of what the project’s objectives and ground rules were…and if Carl believed it were doing so, that would be a particular accomplishment. But we can’t be held hostage to it if that’s not going to pan out.
Hence the name “Beta/One”. When it’s unleashed to the world, it will either be Rebol 3 Beta or Something-Else version One.
I am starting to tag Trello issues with “Beta/One Locked” to indicate that the behavior in that card is considered, with fair confidence, to not be changing. The concept of this lock/freeze is that any code samples on that card should be vetted and work as written…and that the text of the card be basically all truthy.
As a show of seriousness about this, the card describing the new null behavior is Beta/One Locked. That might seem pretty cocky considering the behavior on that card just changed this week. But I know when something is right. I may get excited over a new behavior, but that excitement is different from when you know you have found the solution. And that is the solution.
Still, there are a lot of cards, and a lot of work, and a lot of big question marks all over the place.
In a prior discussion thread on stable releases, I said:
I know people are off on other things and can’t devote their lives to a strange volunteer project. I don’t hold anyone to the standard that they can’t go AWOL if something more important comes up. If you don’t make any specific promises, you don’t have any specific responsibilities.
And I allow myself that too. I was more or less on vacation last month, and didn’t do a whole lot of programming–though I did do some, and I’ve always got a couple of things in my mind. I’ll probably be back on the road again shortly after a foot sprain heals up (it’s doing pretty well). If I find something more interesting to do with my time, development may slow down, and that’s just the breaks.
But this comes down to a you-get-what-you-give situation. If people want to get to Beta/One faster, they’ll put in time to discuss and work and help lock down more of the issues. If you are happy to see it happen whenever it happens, then just wait and see. Odds are cool things will happen, just not on any particular timeline.