Editing Task:Providing changes since last version of a package

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

== Background ==

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.

== Problems ==

=== 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".

=== ChangeLog ===
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.

An example:
 <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 Tim Teulings]

=== 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]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Task:Providing_changes_since_last_version_of_a_package"

@@ Line 17: / Line 17: @@
 An example:
-<source lang="xml">
   <maemo-release-changelog>
   <revision release-date="2008-07-07 23:05:00" revision="<package revision>">
@@ Line 30: / Line 29: @@
   </release>
   </maemo-release-changelog>
-</source>
-When the XML file isn't found, fallback to ChangeLog and changelog. [Proposed by [[User:framstag|framstag]]]
-I vote for this solution.
+When the XML file isn't found, fallback to ChangeLog and changelog. [Proposed by Tim Teulings]
-Actually a small tool could be created to convert the XML to TXT (thus becoming a regular ChangeLog file)--[[User:anidel|anidel]] 15:33, 10 July 2008 (UTC)
 === Additional header in debian/control ===
@@ Line 41: / Line 37: @@
 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]]
-=== Comparison ===
-(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.--[[User:framstag|framstag]] 19:27, 14 July 2008 (UTC)
-[[Category:Community]]

Personal tools

Navigation

Views

Editing Task:Providing changes since last version of a package