Versioned tag information

[Benjamin Mesing]

Hello,

here is an idea I came up with, when thinking about the discussion of
different tag sets for different releases (thanks Justin for bringing it
up!).

The idea is somewhat borrowed from versioned bugs. If a tag is added to
a package, the tag is submitted together with the version information
for the package.

Let me give an example:
      * we have a package, say "packagesearch", at version 1.3 in
        stable, and 2.2.5 in unstable
      * it is currently assigned the tags "uitoolkit::qt",
        "use::searching", "works-with::software:package" in both stable
        and unstable

Now, someone working on unstable submits the tag
"admin::package-management" for the package and the version he is using
(2.2.5). Like with versioned bugs, the package will, starting from
version 2.2.5, have the tag. The stable version will not have the tag
(packagesearch wasn't capable of managing packages back then).
If someone submits the tag to the stable version, the unstable version
will also have the tag.

Tag sets for stable, testing and unstable could be generated from the
central database, which holds all the versioned tag information.

Some technical thoughts:

Tag submission from a standalone application (like debtags edit) could
be easily enriched with version information, taken from the currently
installed version of the package. If the package is not installed, the
information about the version that would be installed is added.

For online submissions things are a little bit more complicated. The
best way would probably be, to let the user select the release he is
tagging (stable, testing, unstable). The version information would be
resolved at the server side.

One potential problem I see, is if a tag is added to a version in
stable. Since the tag is considered to be added to all newer releases of
the package the tag will also be assigned to the unstable version, which
_might_ be not valid anymore. If this turns out to be an issue, we could
forbid propagation of tags for stable to newer versions.

Finally the maintainer could do the tagging using two fields in the
control file. One for defining diffs, and one for totally redefining the
whole tag-set.
        Tags-Diff: +tag1, +tag2, -tag3
and
        Tag-Set: tag1, tag2, tag3, tag4, tag5

Basically the tag information would be managed in a RCS (revision
control system) fashion, with the added possiblity to introduce tags for
older version. The concept of branching could be used, to fork the tag
database for stable releases, in case we do not want stable tags to be
propagated. 

Though the whole thing might offer some challenges, I believe it would
be worth the effort. 

I am very interested in hearing your thoughts about the whole idea.

Regards Ben