Beta Expiration
[1/14] from: al::bri::xtra::co::nz at: 18-Jan-2001 16:22
Rebol/Core and Rebol/View Beta expire soon.
REBOL/core (Experimental) 2.4.39.3.1
Copyright 1997-2000 REBOL Technologies
>> Beta-Expiration-Date
== 21-Jan-2001/15:36:44-8:00
REBOL/View 0.10.38.3.1 28-Nov-2000
Copyright 2000 REBOL Technologies. All rights reserved.
>> Beta-Expiration-Date
== 27-Jan-2001/13:39:03-8:00
Could an update be done real soon please?
Andrew Martin
Needing a Rebol fix...
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
[2/14] from: larry:ecotope at: 17-Jan-2001 20:22
Hi Andrew
I will second that!!
-Larry
----- Original Message -----
From: Andrew Martin <[Al--Bri--xtra--co--nz]>
To: <[feedback--rebol--com]>
Cc: <[rebol-list--rebol--com]>
[3/14] from: chris:starforge:demon at: 18-Jan-2001 10:46
Andrew Martin wrote:
> Could an update be done real soon please?
Agreed! Especially as my site /needs/ the beta version (the
Linux libc6 ix86 version) to work! The release versions
refuse to work on it (termcap/ncurses issue I think) :((
Chris
--
New sig in the works
Explorer2260 Designer and Coder
http://www.starforge.co.uk
[4/14] from: fantam:mailandnews at: 18-Jan-2001 6:34
Me too!
fantam
[5/14] from: giovanni:cardona at: 21-Jan-2001 14:35
Another vote :)
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
"Miracles happen only to those who believe in them."
* Visit 'The International Order of Sea-Monkey Owners' web site
* http://roads.to/seamonkey
* To subscribe to our monthly news, send a blank email to:
* [instantlife-subscribe--listbot--com]
----- Original Message -----
From: Andrew Martin <[Al--Bri--xtra--co--nz]>
To: <[feedback--rebol--com]>
Cc: <[rebol-list--rebol--com]>
[6/14] from: dlhawley:home at: 22-Jan-2001 14:09
Even worse, the QNX RTP version expired the day after Xmas. I'm to
the point of looking for another language for the project I'm working
on.
What is the point of having expiration built into the code? I can see
a licensing scheme where a separate license file is read, but building
the date into the executable is a real problem. A license file would
allow Rebol Tech to entend all exp versions in one easy step. The
current system means that all versions have to be recompiled. As we
see, some of us are left dead-in-the water for long periods of time.
Furthermore it makes it difficult to allow one to trial a for sale
version like command.
Dave Hawley
Previously, you (Andrew Martin) wrote:
> Rebol/Core and Rebol/View Beta expire soon.
> REBOL/core (Experimental) 2.4.39.3.1
<<quoted lines omitted: 14>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
David L. Hawley D.L. Hawley and Associates 1.503.274.2242
Software Engineer [David--L--Hawley--computer--org]
[7/14] from: al:bri:xtra at: 23-Jan-2001 20:56
Dave Hawley wrote:
> Even worse, the QNX RTP version expired the day after Xmas. I'm to the
point of looking for another language for the project I'm working on.
> What is the point of having expiration built into the code? I can see a
licensing scheme where a separate license file is read, but building the
date into the executable is a real problem. A license file would allow Rebol
Tech to entend all exp versions in one easy step. The current system means
that all versions have to be recompiled. As we see, some of us are left
dead-in-the water for long periods of time. Furthermore it makes it
difficult to allow one to trial a for sale version like command.
I, like, agree 95%.
Andrew Martin
Desparate Rebol...
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
[8/14] from: chris:starforge:demon at: 23-Jan-2001 10:15
David Hawley wrote:
> What is the point of having expiration built into the code? I can see
To date the only RT technologies you can distribute are the /core
binary and /command runtimes? /view is a beta product which is not
ready for commercial deployment. License restrictions are fine if
your users stick to licenses, but few businesses have remained in
business by trusting their users on such things. Building in an
expiration prevents all but the hardcore hackers from deploying
a product comercially. As with a lot of software development
companies, RT needs to maintain an image. If you read the blurb on
the RT site you'll realise it's not aimed at developers, or even
end users for that matter. It's aimed at managers, pen-pushers and
admin people who pay more attention to how many buzzwords there are
in a sentance than the specifications of the product. This image
is not served by allowing people to ship products which rely on
a stable but incomplete product like /view. What happens if
someone develops a product which seems to work fine but, when
shipped, encounters problems with /view? How is that going to
affect the customer? At best it'll make them less open to Rebol,
at worst it could generate a lot of negative publicity that
puts off potential customers and discourages investors.
There are sound business reasons for expiration dates in beta
software. IMO the big "problem" is that RT are so careful in
releasing fairly well programmed betas that people forget that
they are testing incomplete, possibly buggy code rather than the
finished product.
Chris
--
New sig in the works
Explorer2260 Designer and Coder
http://www.starforge.co.uk
[9/14] from: petr:krenzelok:trz:cz at: 23-Jan-2001 14:00
Chris wrote:
> David Hawley wrote:
> > What is the point of having expiration built into the code? I can see
<<quoted lines omitted: 22>>
> they are testing incomplete, possibly buggy code rather than the
> finished product.
I have to agree here, although each coin has two sides. What is more - beta
expiration makes ppl to upgrade! VID code and Core itself are changing from
release to release. Can you imagine tens or hundreds of ppl would post old,
possibly non functional code to public libraries, while newer, not anymore
compatible versions would be out?
There are many changes to View in current beta Link release and there are
even some further changes planned. I know the wait is frustrating, but only
RT can tell us when the wait is likely gonna be over ....
Cheers,
-pekr-
[10/14] from: jeff:rebol at: 23-Jan-2001 8:56
Howdy, Chris:
[ . . . ]
> If you read the blurb on the RT site you'll realise it's not
> aimed at developers, or even end users for that matter. It's
> aimed at managers, pen-pushers and admin people who pay more
> attention to how many buzzwords there are in a sentance than
> the specifications of the product.
That blurb may be aimed at those people (people who pay for
software). But that doesn't mean REBOL is necessarily aimed
that way! RT loves happy, healthy, productive, and faithful
developerz!! (-: To that end we're working on getting out
another CORE release here very shortly. ETA: an epsilon + a
delta added to a fractional portion of a short while.
This next CORE release has so many gazillion fixes and
improvements over 2.3-- it ain't even funny.
[ . . . ]
> There are sound business reasons for expiration dates in
> beta software. IMO the big "problem" is that RT are so
> careful in releasing fairly well programmed betas that
> people forget that they are testing incomplete, possibly
> buggy code rather than the finished product.
Well said. We also need to make some changes between these
betas that break scripts occasionally. We usually only do
this in the interests of elegance, longevity, and that sort
of thing, but it's still been an important option for us to
keep open. Hence the "experimental" title of our betas.
We probably won't have a new VIEW to release by the beta
expiry of the current view, so we'll do as we have twice
before and renew the expiration of the binaries on the
experimental page, have people redownload their REBOL, with
many thank-yous to everyone for their enduring patience.
Believe me, we want to release software, but we really don't
want to release stuff that's not polished to a superior
perfection.
-jeff
[11/14] from: karlr20:home at: 23-Jan-2001 12:59
On Tuesday 23 January 2001 08:56, you wrote:
> Howdy, Chris:
> [ . . . ]
<<quoted lines omitted: 31>>
> perfection.
> -jeff
Superior perfection? Give me a break. REBOL is a piece of code and like all
code has bugs and is incomplete. It comes with the territory. The only
difference between 'beta' code and 'production' code is in the name. Chris
<[chris--starforge--demon--co--uk]> argues that because the ignorant will
think less of the product because it doesn't perform perfectly it should be
crippled.
So REBOL may have a bug which I run across. I deal with it. I find the
point of failure and write the code differently or what not. I've already
had to do this. Or, as Jeff says, I may have to rewrite for a new version.
In this case, I can (or *should* be able to) upgrade at my convenience. But
when the tool *does* work the last thing I need is for it to suddenly stop
working and having to implement an interim solution.
I only found out this week on this list that you could query REBOL for it's
expiration date. Is the 'beta-expiration-date' word described in a document
somewhere that I missed?
We don't need to be protected from ourselves. If I choose to use a beta
version and it works, why should it suddenly stop working at some arbitrary
date? The *only* people I can imagine who would benefit from expiration is
technical support, who wouldn't have to field questions about why feature 'A'
documented in the latest manual doesn't work on the year old beta 'B'. But
that's what technical support is for. The proper solution here is education,
not termination. Beta expiration has no value for me.
-Karl Robillard
Still waiting for REBOL/Source ;)
[12/14] from: rebol:svendx:dk at: 23-Jan-2001 23:52
Hello [jeff--rebol--net]
On 23-Jan-01, you wrote:
-- snip --
> We probably won't have a new VIEW to release by the beta
> expiry of the current view, so we'll do as we have twice
> before and renew the expiration of the binaries on the
> experimental page, have people redownload their REBOL, with
> many thank-yous to everyone for their enduring patience.
Would it be possible to do this for CORE experimentals also ?
(It's quite a time ago since the Amiga version expired...)
> Believe me, we want to release software, but we really don't
> want to release stuff that's not polished to a superior
> perfection.
That's a noble goal!
> -jeff
>
Best regards
Thomas Jensen
[13/14] from: carl:cybercraft at: 24-Jan-2001 14:20
On 24-Jan-01, Karl Robillard wrote:
> Superior perfection? Give me a break. REBOL is a piece of code and
> like all code has bugs and is incomplete. It comes with the
> territory. The only difference between 'beta' code and 'production'
> code is in the name.
I beg to differ. I consider the difference to be that the
production
code is considered by RT to be of a high enough standard
to be used for serious work, that changes to it won't be happening on
a weekly or even monthly basis, and that any upgrades to it are more
likely to be of the bug-fixs and extensions kind than of the "we've
changed this and it'll probably break your scripts" kind.
Beta's on the other hand may have all of the above problems, but then
betas are not made public for people to use for serious work, but to
give those interested an idea of where the software is heading and to
give its producers feedback about it. I find the expirations
annoying too, but it does makes sense. What if one of the
experimental versions had a security flaw? A lot harder to exploit
it when everyone's stopped using it because it's expired.
> I only found out this week on this list that you could query REBOL
> for it's expiration date. Is the 'beta-expiration-date' word
> described in a document somewhere that I missed?
Which is another difference about betas - the full docs come only
*after* they leave beta. (:
--
Carl Read
[carl--cybercraft--co--nz]
[14/14] from: dlhawley:home at: 23-Jan-2001 10:14
Previously, you (Chris) wrote:
> David Hawley wrote:
> > What is the point of having expiration built into the code? I can see
<<quoted lines omitted: 17>>
> at worst it could generate a lot of negative publicity that
> puts off potential customers and discourages investors.
No real company is going to ship a product which requires monthly
or quarterly update of a license whether (although REBOL would make
fairly transparent to do so). There's not much difference between
embedding the license into the code and having a seperate file -
although I'm coming from the QNX point fo view where the OS does this
for you.
Still my gripe is unanswered. The QNX4 and RTP experimental versions
of core expired on 12/27/2000. I've been trying to develop a product
which requires serial port support, but I haven't been able to do
anything since then because the license is expired and I don't like to
turn back th clock on my computer. If the exp license was a file, then
I'd think that it would be pretty easy for you guys to keep that going
even though you're stuck on parts of core for some platform with higher
priority than QNX. As I noted to support, I can work around things like
serial port opens that always set baud rate to 0 pretty easily, but
I'm dead in the water without a license.
Your site may be aimed at managers, but developers are the ones using
the language and if you turn them off it won't matter what the
managers want.
> There are sound business reasons for expiration dates in beta
> software. IMO the big "problem" is that RT are so careful in
> releasing fairly well programmed betas that people forget that
> they are testing incomplete, possibly buggy code rather than the
> finished product.
I agree that it makes a lot of sense to expire beta code, but only
if you can keep up with the built in time frame.
--
David L. Hawley D.L. Hawley and Associates 1.503.274.2242
Software Engineer [David--L--Hawley--computer--org]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted