On Thu, 2002-10-17 at 00:49, Justin Erenkrantz wrote:
> I'd prefer to come up with strict versioning rules for httpd before
> proceeding further. I'm slightly concerned that we're starting to
> move away from the 'versions are cheap' ideology. Currently, we
> place no meaning on the version nu
"William A. Rowe, Jr." wrote:
> What's the penalty for stable/development trees? Users don't have
> the development code (at least not many) for some time, until the
> development tree becomes GA quality. But that's how it should be,
> and that's the only way we will ever find 1.3 adopters movin
* G?nter Knauf ([EMAIL PROTECTED]) wrote :
> Hi,
>
[...]
> changing the MMN isnt the worse thing, but doing so without any documentation is!
> What I expect is a list that shows for every MMN change a short description why it
>was changed or better what has changed in the sources, and if it affe
> At the risk of racing too far ahead in this discussion, here is my
> suggestion... 2.0.43 becomes 2.1 and the MMN major does not change
> for subsequent 2.1 series releases (except for a compelling reason,
> eg a security fix -requires- a bump). Why 2.1? No technical
> reason; purely a PR tact
On Wed, Oct 16, 2002 at 03:40:55PM -0500, Thomas Eibner wrote:
> > What I expect is a list that shows for every MMN change a short description why it
>was changed or better what has changed in the sources, and if it affects third-party
>modules and which, f.e. something like that:
> >
> > 20020
At 06:43 PM 10/16/2002, Greg Marr wrote:
>On Wed, 16 Oct 2002 19:24:22 -0400
> Joshua Slive <[EMAIL PROTECTED]> wrote:
>>I'm +1 for creating 2.1 and 2.2 trees as proposed by Bill.
>
>My one thought about this proposal is that it is unclear whether or not this is
>attempting to emulate the Perl ve
On Wed, 16 Oct 2002, Aaron Bannert wrote:
> > I like.
>
> I also like, but I also think we should stick with the "even numbered
> revisions are stable, odds are developmental" axiom.
Definitely agreed.
--Cliff
On Tue, Oct 15, 2002 at 10:22:46AM -0400, Jim Jagielski wrote:
> Bill Stoddard wrote:
> >
> > At the risk of racing too far ahead in this discussion, here is my
> > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> > subsequent 2.1 series releases (except for a compelling r
Quoting Greg Marr <[EMAIL PROTECTED]>:
> On Wed, 16 Oct 2002 19:24:22 -0400
> Joshua Slive <[EMAIL PROTECTED]> wrote:
> >I'm +1 for creating 2.1 and 2.2 trees as proposed by Bill.
>
> My one thought about this proposal is that it is unclear whether or
> not this is attempting to emulate the P
+1 for a 2.1 tree
Why? :
When a securityproblem/bug is found in 2.0.43, then I excpect to
get a new version who is just a "drop-in" replacement for it.
What can be accepted is
- To have to recompile all modules
- Make sourcecode changes to the modules if AND ONLY IF the api change
is directl
On Wed, 16 Oct 2002 19:24:22 -0400
Joshua Slive <[EMAIL PROTECTED]> wrote:
>I'm +1 for creating 2.1 and 2.2 trees as proposed by Bill.
My one thought about this proposal is that it is unclear whether or
not this is attempting to emulate the Perl versioning scheme. If so,
then it's backwards,
I'm +1 for creating 2.1 and 2.2 trees as proposed by Bill.
The current auth-docs problems can be fixed (and, in fact, André has
already gotten us most of the way there), but things would be much
cleaner with a new tree.
I also believe this would better communicate with users the current
state
On Wed, Oct 16, 2002 at 08:32:34PM +0200, G?nter Knauf wrote:
> Hi,
>
> > "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > First, I'm pretty happy with what is going on in 2.0 HEAD now. I
> > don't think MMN is changed gratuitously, I don't think the code gets
> > destabilized a whole l
Hi,
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> First, I'm pretty happy with what is going on in 2.0 HEAD now. I
> don't think MMN is changed gratuitously, I don't think the code gets
> destabilized a whole lot on a regular basis, I think that having some
> aspects of the config chan
> Just an opinion..
> Lots of people trust you lot. Next time there is a security issue and
> you do release 2.0.x, if there is a change/new functionality that is
> beta, alpha or worse then that is extremely bad for a GA product. Start
> the 2.1.x branch!
I'll state this a slightly different way
Just an opinion..
Lots of people trust you lot. Next time there is a security issue and
you do release 2.0.x, if there is a change/new functionality that is
beta, alpha or worse then that is extremely bad for a GA product. Start
the 2.1.x branch! Agree rough timescales bearing in mind you may need
On Wed, 2002-10-16 at 02:23, Jeff Stuart wrote:
> Not to make a me too post BUT.. me too. I've been using apache 2. on
> non critical projects or where I MUST use apache 2. (IE Subversion
> repository). So far, it's stable BUT (and I stress this HIGHLY) it's
> not been pounded on AT all. IE at
On Tue, 2002-10-15 at 10:46, Thom May wrote:
> * Jim Jagielski ([EMAIL PROTECTED]) wrote :
> > Bill Stoddard wrote:
> > >
> > > At the risk of racing too far ahead in this discussion, here is my
> > > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> > > subsequent 2.1 seri
On Tue, 15 Oct 2002, Bill Stoddard wrote:
> Worth reading...
> http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2882203,00.html
On October 2nd; *after* RedHat 8.0 was released he wrote "And I
doubt Red Hat will make 2.0 the default install until [...]".
Really Impressive Predictions.
i'm responding to the head of this thread because i haven't read
the rest of it yet.. so, as usual, my comments may be stale.
Jeff Trawick wrote:
>
> . let 2.0 HEAD proceed as it seems to be going now
:
> . let those who are interested (not more than a few would be needed to
> make it
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> It seems that the 'maintainers', the stodgy 'old men' of the group, want
> everyone to row together on bug fixes. That isn't how OS works. The
> folks with no interest in tracking down obscure bugs just leave, or
> quietly bide their time. T
* Jim Jagielski ([EMAIL PROTECTED]) wrote :
> Bill Stoddard wrote:
> >
> > At the risk of racing too far ahead in this discussion, here is my
> > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> > subsequent 2.1 series releases (except for a compelling reason, eg a
> > sec
> At the risk of racing too far ahead in this discussion, here is my
suggestion...
> 2.0.43 becomes 2.1 and the MMN major does not change for subsequent 2.1
series
> releases (except for a compelling reason, eg a security fix -requires- a
bump). Why
> 2.1? No technical reason; purely a PR tactic
Bill Stoddard wrote:
>
> At the risk of racing too far ahead in this discussion, here is my
> suggestion... 2.0.43 becomes 2.1 and the MMN major does not change for
> subsequent 2.1 series releases (except for a compelling reason, eg a
> security fix -requires- a bump). Why 2.1? No technical re
> At 08:16 AM 10/15/2002, Bill Stoddard wrote:
> >> After a million messages on related topics, I'm not sure that any two
> >> developers agree on all of the following topics:
> >>
> >> . how much to consider the needs of users relative to desires of
> >> developers
> >>
> >> . how hard to try
At 08:16 AM 10/15/2002, Bill Stoddard wrote:
>> After a million messages on related topics, I'm not sure that any two
>> developers agree on all of the following topics:
>>
>> . how much to consider the needs of users relative to desires of
>> developers
>>
>> . how hard to try not to break bina
> After a million messages on related topics, I'm not sure that any two
> developers agree on all of the following topics:
>
> . how much to consider the needs of users relative to desires of
> developers
>
> . how hard to try not to break binary compatibility
>
> . how much to use 2.0 HEAD as a
After a million messages on related topics, I'm not sure that any two
developers agree on all of the following topics:
. how much to consider the needs of users relative to desires of
developers
. how hard to try not to break binary compatibility
. how much to use 2.0 HEAD as a sandbox for ne
28 matches
Mail list logo
