On Sun, 13 Oct 2002, Greg Stein wrote: > On Sat, Oct 12, 2002 at 06:18:41PM -0400, [EMAIL PROTECTED] wrote: > >... > > I think there is a much easier way to satisfy everybody and stay in the > > 2.0 tree. The problem right now, is that the MMN isn't granular > > enough. All we know, is that we broke binary compatibility. But, we > > don't know where it was broken, which means that all modules must be > > re-compiled. But, let's take the auth changes as an example. We had to > > bump the MMN with these changes, because of what was done. But, the only > > modules that were affected, were auth modules. That means that anybody > > Woah! Totally not true. > > The auth changes DID NOT affect MMN. And they DID NOT affect other auth > modules. > > All the focus around this stuff is a sensitive issue. Let's not make it > worse with misinformation. I know it wasn't intentional, but let's not let > it spread. > > The auth change *added* stuff. It absolutely did not change any APIs, so > there was no need for an MMN bump. > > That said, there probably should have been a "minor" bump so that code can > test whether an API is present. But minor bumps are totally righteous. No > problem with those.
OK. My bad. I am completely incorrect, and I take the blame for that. Sorry. > >... > > If we modularize the MMN, and provide a way for module authors to query > > the MMN at a granular level, most of the MMN bumps become much more > > trivial. Let me explain what I mean. > > +1 on the concept. > > Along these lines, I've wanted to go into the new provider stuff that Justin > added and add a provider-version number. That would allow a person to > register a particular version of a provider. This is especially important > because I want to make big changes to the mod_dav API, but (today) that > would imply an MMN bump. If I can introduce a provider API version, then > changes to the mod_dav interface would not kill the whole server -- just DAV > providers. I would prefer one API for the provider/MMN check, so I will try to throw something together this week. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
