You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1995/12/05 06:13:51 UTC
Re: Version Control
On Sun, 3 Dec 1995, Ben Laurie wrote:
> "Apache 1.0.0 will be copied to Apache 1.1x.0, bugfixes _only_ will be applied
> to 1.0.?, and all other code will go into 1.1x.?"
>
> My vote is, natch, +1.
What I think you mean is
"Patchlevel revisions (i.e., increments in the number after the second
'.') are meant to be bugfixes *only* - new functionality, when it's not
the result of a bugfix, will be released when the minor version
increments, and major version increments signify a major shift in the
functionality of the server."
So yeah, 1.0.x will have *no* extra functionality over 1.0.0, likewise
1.1.x will have no major functionality over 1.1.0, but 1.1.0 will contain
every bugfix from the last release of 1.0.x.
I don't see any other way to do it.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Version Control
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Mon, 4 Dec 1995, Brian Behlendorf wrote:
> 1) just 1.x.0 + bugfixes
> 2) 1.x.0 + bugfixes + new features
>
> I think this is what you and I want.
Yes. I agree with this. So can someone make a for_Apache_1.1a1 directory?
(let's take alpha to mean bugfixes + features and beta to mean bugfixes +
features + bugfixes for the features). Hmm. except the way the patches
directory is set up now, for means what version do they patch. I always
thought that was a bit counterintuitive anyhow - for should mean where
it's going to, not coming from. What say we move for_Apache_1.0.0 to
for_Apache_1.0.1, make a for_Apache_1.1a1, and rewrite the voting/patching
rules to match? Oh, and toss my userdir patch into one of those
directories, while you're at it :)
(the a1 one probably - patch 02 from the current for_Apache_1.0.0 should
prolly go there too, if we can agree on this.)
+1 on above. (if it means anything)
--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------
Re: Version Control
Posted by Brian Behlendorf <br...@organic.com>.
On Mon, 4 Dec 1995, Alexei Kosut wrote:
> On Mon, 4 Dec 1995, Brian Behlendorf wrote:
> > What I'm trying to avoid is inconsistancy - say, 1.0.1-1.0.7 is a bug
> > fix, but then we add persistant connectins to 1.0.8, and people don't
> > pick up on it.
>
> But my question is - when do we add persistant connections then? Between
> 1.0.99 and 1.1? But in the case between 0.8.17 and 1.0, there *was* no in
> between. And if we wait forever for 1.1 to come out, people will get
> annoyed. But we can't just spend a couple days or weeks on "new
> features". It should be an ongoing process. What if I decide to patch
> persistent connections into Apache just after 1.1.0 comes out. Do I have
> to sit on the patch until it's time for 1.2.0?
We have two development trees:
1) just 1.x.0 + bugfixes
occasionally released as 1.x.1, 1.x.2
this is labeled "STABLE".
2) 1.x.0 + bugfixes + new features
occasionally released as 1.(x+1)a1, 1.(x+1)a2, 1.(x+1)b1, 1.(x+1)b1,
until 1.(x+1).0.
This is labeled "EXPERIMENTAL". "USE AT YOUR OWN RISK". "DO NOT TRY
THIS AT HOME", etc. :) [1]
The "occasionally" in #2 is not synchronous necessarily with the
"occasionally" in #1.
I think this is what you and I want.
Brian
[1] - anyone ever read the Java use license? They, uh, ask you to not
use it to run a nuclear power plant, among other things. :)
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Version Control
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Mon, 4 Dec 1995, Brian Behlendorf wrote:
> No. That's just not the way that numbering happens in other arenas.
> Check it out - how many people pass up the X.0 version, waiting instead
> for X.1, knowing that in *any* piece of new code there will be bugs and
> problems waiting to get ferreted out by a large user base. GCC 2.7.0 is
> out, and I'm waiting till 2.7.1 at least before switching over to it.
> Look at Windows 3.1.1... Netscape 1.1...
I'm not disagreeing with you yet... (agreeing in fact)
> You basically outlined the same thing I did, but you added "Xbx"
> notation, and I would have expected that to be the case anyways. Yes,
> 1.0 will be as bug free as *we* can make it, but it won't truly be
> de-roached until the mass public has gotten a hold.
Okay.
> What I'm trying to avoid is inconsistancy - say, 1.0.1-1.0.7 is a bug
> fix, but then we add persistant connectins to 1.0.8, and people don't
> pick up on it.
But my question is - when do we add persistant connections then? Between
1.0.99 and 1.1? But in the case between 0.8.17 and 1.0, there *was* no in
between. And if we wait forever for 1.1 to come out, people will get
annoyed. But we can't just spend a couple days or weeks on "new
features". It should be an ongoing process. What if I decide to patch
persistent connections into Apache just after 1.1.0 comes out. Do I have
to sit on the patch until it's time for 1.2.0?
> Sure, but an announcement goes out only at 1.1.0, 1.2.0, etc.
Fine. But again, when do we have the interim releases, with new features?
Like the whole 0.3-0.6 set of releases. Or 0.8. It took us 17 releases to
get that straight, over a period of almost a year.
> So, I *think* we're saying the same thing, you just added the notation
> for early beta releases.
I'd take what you just said to be "early" to be most of the process. Let
me recap what I am saying:
We just released Apache 1.0.0. As bugs develop (as they already have), we
release 1.0.1, 1.0.2, etc...
But we can't just wait until Apache 1.0 is bugless (which it never will
be) to put in new features. We've been waiting too long already. Neither
can we release 1.1 right after we just released 1.0, with new features,
and it would be buggy anyway! And you don't want 1.0.x to have new
features. So now what? We're at an impasse.
I am proposing to have a run in between 1.0.x and 1.1.0, which I am
calling 1.1bx. This would last for a *long* period of time, until
1.1b999, which could be in mid-96 or so, and would be stable and without
major bugs. We then call that 1.1.0, and start in with 1.2b1.
See what I'm trying to say here? We need more time then you're giving us
with your plan.
--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------
Re: Version Control
Posted by Brian Behlendorf <br...@organic.com>.
On Mon, 4 Dec 1995, Alexei Kosut wrote:
> On Mon, 4 Dec 1995, Brian Behlendorf wrote:
>
> > So yeah, 1.0.x will have *no* extra functionality over 1.0.0, likewise
> > 1.1.x will have no major functionality over 1.1.0, but 1.1.0 will contain
> > every bugfix from the last release of 1.0.x.
>
> Wait just one darn minute here. This means that the release of 1.1.0 is
> the *only* time we're allowed to put in new features? Not only is this an
> incredibly short period of time (if the wait for 1.0 is any indication),
> but it gives no chance for bugs to be worked out, if we would like the
> *.0 released to be relatively bug-free.
No. That's just not the way that numbering happens in other arenas.
Check it out - how many people pass up the X.0 version, waiting instead
for X.1, knowing that in *any* piece of new code there will be bugs and
problems waiting to get ferreted out by a large user base. GCC 2.7.0 is
out, and I'm waiting till 2.7.1 at least before switching over to it.
Look at Windows 3.1.1... Netscape 1.1...
> I'd go for something like what the rest of the world does, tack a
> development number on the end. We have 1.0, bug fixes for that go into
> 1.0.1, 1.0.2, etc... meanwhile, we work on 1.1b1, 1.1b2, up through
> 1.1b100 if we like, then release 1.1.0 when we're satisfied its good, and
> 1.1.1 and 1.1.2, etc are bugfixes for that. Meanwhile we work on 1.2b1,
> etc...
You basically outlined the same thing I did, but you added "Xbx"
notation, and I would have expected that to be the case anyways. Yes,
1.0 will be as bug free as *we* can make it, but it won't truly be
de-roached until the mass public has gotten a hold.
What I'm trying to avoid is inconsistancy - say, 1.0.1-1.0.7 is a bug
fix, but then we add persistant connectins to 1.0.8, and people don't
pick up on it.
> They can (should) be public betas most of the time.
Sure, but an announcement goes out only at 1.1.0, 1.2.0, etc.
So, I *think* we're saying the same thing, you just added the notation
for early beta releases.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: Version Control
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Mon, 4 Dec 1995, Brian Behlendorf wrote:
> So yeah, 1.0.x will have *no* extra functionality over 1.0.0, likewise
> 1.1.x will have no major functionality over 1.1.0, but 1.1.0 will contain
> every bugfix from the last release of 1.0.x.
Wait just one darn minute here. This means that the release of 1.1.0 is
the *only* time we're allowed to put in new features? Not only is this an
incredibly short period of time (if the wait for 1.0 is any indication),
but it gives no chance for bugs to be worked out, if we would like the
*.0 released to be relatively bug-free.
> I don't see any other way to do it.
I'd go for something like what the rest of the world does, tack a
development number on the end. We have 1.0, bug fixes for that go into
1.0.1, 1.0.2, etc... meanwhile, we work on 1.1b1, 1.1b2, up through
1.1b100 if we like, then release 1.1.0 when we're satisfied its good, and
1.1.1 and 1.1.2, etc are bugfixes for that. Meanwhile we work on 1.2b1,
etc...
They can (should) be public betas most of the time. But I think this
would work best, and be the least confusing for the public. After all,
when you see 1.0.1, say, vs. 1.1.0, wouldn't you pick 1.1.0, even if it's
riddled with bugs? But you wouldn't know that. In a choice between 1.0.1
and 1.1b4, it's readily evident that 1.1b4 is a beta, probably doesn't
work right... you can run it if you want.
I'll +1 that idea.
--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------