Task:Providing changes since last version of a package
(→Comparison) |
(→Comparison) |
||
| Line 43: | Line 43: | ||
=== Comparison === | === 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.--[[ | + | (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) |
Revision as of 19:27, 14 July 2008
Contents |
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="Invalid language.
You need to specify a language like this: <source lang="html4strict">...</source>
Supported languages for syntax highlighting:
abap, actionscript, actionscript3, ada, apache, applescript, apt_sources, asm, asp, autoit, avisynth, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_mac, caddcl, cadlisp, cfdg, cfm, cil, cmake, cobol, cpp, cpp-qt, csharp, css, d, dcs, delphi, diff, div, dos, dot, eiffel, email, erlang, fo, fortran, freebasic, genero, gettext, glsl, gml, gnuplot, groovy, haskell, hq9plus, html4strict, idl, ini, inno, intercal, io, java, java5, javascript, kixtart, klonec, klonecpp, latex, lisp, locobasic, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, make, matlab, mirc, modula3, mpasm, mxml, mysql, nsis, oberon2, objc, ocaml, ocaml-brief, oobas, oracle11, oracle8, pascal, per, perl, php, php-brief, pic16, pixelbender, plsql, povray, powershell, progress, prolog, properties, providex, python, qbasic, rails, rebol, reg, robots, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, sql, tcl, teraterm, text, thinbasic, tsql, typoscript, vb, vbnet, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xml, xorg_conf, xpp, z80