You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1997/10/01 01:28:01 UTC
Re: [STATUS] 1.3b1: Tue Sep 30 10:00:33 PDT 1997
>How about a new release level: Final Candidate? We work on betas
>which reflect a work-in-progress. When we have a version that
>we think is stable enough to be the possible true release, it's
Ummm, terminology ... "stable" means it isn't likely to change,
not that its highly reliable. A version that always crashes is stable.
What we need is a category for "on the cutting edge, but more reliable
than our last stable release".
Oh, and I still think they should be number 1.3.0, 1.3.1, ... from the
get go. *shrug*
....Roy
Re: [STATUS] 1.3b1: Tue Sep 30 10:00:33 PDT 1997
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
> On a more real note; Ben: You say you're voting +1 for 1.3b1. Does
> that mean you've solved all the issues neccessary to make an
> acceptable Windows binary that we can distribute and idiots can
> install and make working without too much trouble (and some
> directions)?
Hmmm. Not quite. Firstly, I'm voting +1 on the basis that Windows
shouldn't hold up testing on Unix. Secondly, Windows has some strange
problems that will take some time to solve if I'm the only one working
on them (I move house next week, so I'll be even busier than usual), and
could do with some more eyes. Thirdly, I may finally be in a position to
actually install InstallShield, so I _may_ be able to roll a nice
installation package, and finally, if I can't, well, the most valuable
input at this stage would still be from people with compilers.
> Unforunately, I still don't have a Windows machine. I should soon,
> some way or another. However, I've discovered I can use CodeWarrior on
> my Mac to cross-compile to Windows (it comes with the full set of
> Microsoft libraries and headers, as well) as an x86
> compiler/linker. Something tells me, however, this is not the best way
> of doing Windows development...
I think you may be right.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: [STATUS] 1.3b1: Tue Sep 30 10:00:33 PDT 1997
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 30 Sep 1997, Alexei Kosut wrote:
> Very different from, say, the Linux development model, which works
> more like how Apache used to, circa 0.7, where Linus will (and this is
> secondhand knowledge) sometimes release kernels without even checking
> to see if they compile first.
This is only for development series of kernels -- the stable series
generally compile. He's known to do complete rewrites of sections of the
kernel during development series, get the bits he needs to work with it,
and then release it. Other folks have to bring their devices, fs code, or
networking code up to date by submitting a patch back to him. In this
case those things almost certainly don't compile (unless you happen to
have the exact same config as Linus).
Dean
Re: [STATUS] 1.3b1: Tue Sep 30 10:00:33 PDT 1997
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Tue, 30 Sep 1997, Dean Gaudet wrote:
> I'd be happy with us releasing 1.3.0 now and calling it unstable ;) We'd
> be closer to target then!
>
> Seriously, I don't mind a naming scheme that goes 1.3.0, 1.3.1, ... and we
> periodically call things stable releases. But I'm not up for debating
> this stuff, status quo works for me.
It's interesting. Back before 1.1, we did work that way. 0.8.0-0.8.14,
for examine, none of which were even remotely "stable" :) This was
neccessary because
a) Most of the people using Apache were developers, so there wasn't
a real point to differentiating reliable or reference releases
(or at least, we didn't care to).
b) There was no "development" source. We collected patches and put
them together to form a new release. The only way to make sure
that the developers could coherently code anything was to make lots of
releases, to keep people in sync.
Then we discovered CVS. CVS is great, but it means that any of *us*
can get a current release, with everyone's accepted patches, by typing
a few characters. I'd bet that most of the developers here run -dev
versions of Apache on their own sites; there isn't as much direct
impetus to make a real release.
But also, we've adopted a very commercial (if you will) viewpoint to
release management, where a final release, e.g. 1.3.0, is final. It's
supposed to work perfectly. Even our beta releases are "supposed" to
be close to finished, just with some bugs to fix. There's nothing
wrong with this, it's just the way we work.
Very different from, say, the Linux development model, which works
more like how Apache used to, circa 0.7, where Linus will (and this is
secondhand knowledge) sometimes release kernels without even checking
to see if they compile first.
In a recent thread I saw somewhere on bazaar vs. cathedral styles of
product management, someone mentioned Apache as a bazzar-oriented
product. I just had to laugh...We may not have a Pope, but we are
definitely an organized religion :)
On a more real note; Ben: You say you're voting +1 for 1.3b1. Does
that mean you've solved all the issues neccessary to make an
acceptable Windows binary that we can distribute and idiots can
install and make working without too much trouble (and some
directions)?
Unforunately, I still don't have a Windows machine. I should soon,
some way or another. However, I've discovered I can use CodeWarrior on
my Mac to cross-compile to Windows (it comes with the full set of
Microsoft libraries and headers, as well) as an x86
compiler/linker. Something tells me, however, this is not the best way
of doing Windows development...
-- Alexei Kosut <ak...@nueva.pvt.k12.ca.us>
Re: [STATUS] 1.3b1: Tue Sep 30 10:00:33 PDT 1997
Posted by Dean Gaudet <dg...@arctic.org>.
I'd be happy with us releasing 1.3.0 now and calling it unstable ;) We'd
be closer to target then!
Seriously, I don't mind a naming scheme that goes 1.3.0, 1.3.1, ... and we
periodically call things stable releases. But I'm not up for debating
this stuff, status quo works for me.
Dean
On Tue, 30 Sep 1997, Roy T. Fielding wrote:
> >How about a new release level: Final Candidate? We work on betas
> >which reflect a work-in-progress. When we have a version that
> >we think is stable enough to be the possible true release, it's
>
> Ummm, terminology ... "stable" means it isn't likely to change,
> not that its highly reliable. A version that always crashes is stable.
> What we need is a category for "on the cutting edge, but more reliable
> than our last stable release".
>
> Oh, and I still think they should be number 1.3.0, 1.3.1, ... from the
> get go. *shrug*
>
> ....Roy
>