Re: multiple releases (was: Re: [PEAR-DEV] [Draft] Pear web)

["Tomas V.V.Cox" <cox@idecnet.com>] > "Tomas V.V.Cox" wrote: > > > > Stig Sæther Bakken wrote: > > > > > > ["Tomas V.V.Cox" <cox@idecnet.com>] > > > > >In the other hand want to do with the changelog? In the > > past I was against of leaving the changelog in the package.xml, but now > > guess that it will make things easier for us. What about: > > > > <Releases> > > <Release> > > <Version>1.1</Version> > > <State>(alpha|beta|devel|stable|cvs)</State> > > <Date>2002-1-1</Date> > > <Notes>blah</Notes> > > </Release> > > </Releases> > > > > > > The first release of devel/stable found while parsing will be the values > > to fill in develrelease/stablerelease columns of packages table. > > > > Umm, I met me with a problem here. What release should choose the > packager? I guess we shouldn't mix the release tag with the chagelog. > > <Release> //or perhaps <Current>? > (version|state|date|notes) > </Release> > <Changelog> > <Release> > (version|state|date|notes) > </Release> > </Changelog> Hold on, the overlapping functionality monster is finally coming for us now. Pear.php.net's database will store release information etc, and if we intend to make the "release upload form" there _the_ place to do releases, we need to generate parts of all of the package.xml files (maintainers section, release information etc). I also don't see a point in having a complete release history in the package.xml file, there could be a separate history file for that (easily generated). Really, the only information in package.xml that can not be generated/updated from the database is the file listing. - Stig -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway