From: Andy S. <an...@ee...> - 2005-10-18 07:06:26
|
+1 for API changes. Try to involve the module developers more. E.g. - Port the API changes forum topic to a shiny codex page. - For each API change, show example code how to modify an existing module to match the new API - Create a new mailinglist for module developers where we can announce API changes or use the existing -devel mailinglist (why not?). That were measures to encourage module developers to keep their module up to date. A) We still need versions of modules that are compatible with older API versions. B) And users shouldn't be confused with the module / API version stuff Downloadable modules in conjunction with getting all the user contributed modules into a "unoffical modules" repository will eliminate B) since we will only offer compatible modules for download. But A) is a little difficult. We should have a module developer help page where we show the current API versions that should be developed against. Current = API of last official release + API of current CVS version. And explain the differences. - Andy Bharat Mediratta wrote > > > I'm working on reducing the G2 footprint (in disk space, > memory space and latency) and one of the things that's next > on my agenda is to aggregate all of our generated .sql files > into one single file. This will have the effect of > converting ~180 .sql files into ~8 schema.tpl files. Because > typical large disks these days have 4K block sizes and the > .sql files are smaller than 4K, this will result in a > significant savings in disk space, as well as ease the pain > for folks who are using ftp to upload G2 to their webserver. > > The downside is that in order for this to work, we have to do > an API change. The code that's currently committed supports > the new style, but is backwards compatible. This allows us > to avoid bumping the module API major revision number. But > if we change the SQL generation code to put it into a single > file, then it means that all new modules that we develop > against CVS HEAD during the 2.1 dev cycle that create > entities/maps will not work on 2.0 because their generated > SQL will be in a place that 2.0 can't find. > > Right now we've got a lot of new user contributed modules: > > http://codex.gallery2.org/index.php/Gallery2:User_Contribution > s#Modules > > We're getting more every day. If we change the API version > then we'll have to start recording which API versions these > modules work against, and our module developers will have to > commit to one version (whichever one they're on) or be forced > to fork. Either way I think it's confusing for our users who > want to try out new modules. > > On the other hand, if we DON'T make API changes then we're > not making the kind of progress that we *could* make in this > release. That doesn't sound so appealing to me either. > > Neither of these options sounds appealing to me. Can anybody > think of a good third option? > > -Bharat |