Task:Providing changes since last version of a package
For the Application Manager and downloads.maemo.org it would be nice to have automatically updated information about changes since last version of a package. It would be good to have the change information available inside a package.
 debian package changelog
The debian package changelog describes changed to the package made by the package maintainer. If maintainer and developer are different a changelog entry for a major relase could just contain "New upstream version".
Another option would be to use the ChangeLog of the original source package - this would contain upstream documentation to changes in the original software. You would expect to find new features there. However upstream information might contain information of varying detail. Another problem is that the ChangeLog is "owned" by upstream, the maintainer can/should not change it.
 Proposed solutions
 XML file
Add a Maemo specific XML file for each package.
<maemo-release-changelog> <revision release-date="2008-07-07 23:05:00" revision="<package revision>"> <description> Packages new upstream version. </description> </revision> <release release-date="2008-07-01 11:55:00" version="<source package version>"> <description> Now plays funny sound on start. </description> </release> </maemo-release-changelog>
When the XML file isn't found, fallback to ChangeLog and changelog. [Proposed by framstag]
I vote for this solution. Actually a small tool could be created to convert the XML to TXT (thus becoming a regular ChangeLog file)--anidel 15:33, 10 July 2008 (UTC)
 Additional header in debian/control
I wonder whether another header would be sufficient in debian/control? We've already got XB-Maemo-Icon, adding XBS-Version-Changes or something could be sufficient.
Certainly for downloads.maemo.org; for more detail the debian/changelog is available and /should/ be the definitive location so we don't diverge too much from other Debian-based systems. --User:jaffa
(Commenting on my own proposal): I both suggestions as valid and good ideas. However they solve different problems. My proposal collects more data than acutally required to display the latest change (it has history) and is thus more complex, while the other solutions is far simpler and exactly fits the initial requirement. So the questions is: How much changelog do we need? For what purpose? If we do not find more purpose then initially requested I would suggest to start with the header aproach - just because it is simpler.--framstag 19:27, 14 July 2008 (UTC)
- This page was last modified on 24 February 2011, at 14:19.
- This page has been accessed 10,779 times.