On Wed, Feb 03, 2010 at 03:14:09PM +0100, Stefano Zacchiroli wrote: > > I personally don't particularly like the idea of faking dates to mean > something specific such as "not release yet". On the other hand I like > the idea of storing the release date because it is an information per se > and might be useful as such.
ACK. > Now, according to that principle, a possible proper way of storing > release dates would be to have the corresponding field NULLABLE and > store NULL for suites not yet released. That way released suite can be > easily sorted by date, taking care of filtering out NULL values before > hand. What do you consider as proper release date for *-security and *-proposed-updates (NULL, same as release or my suggestion releasedate + 1/2 days). > That of course leave the problem of how to respectively sort squeeze, > sid, and experimental. I do wonder however if it is really needed to do > that; I'd vote for having a defined sorting between squeeze (= current testing) and sid because it is definitely ordered in the sense of "some existing point in the future" and "infinite" (=never). > after all sid can well have a version of a package which is newer > than its version in experimental and vice-versa, the same is potentially > true for testing. You mean testing can have a never version as experimental? Yes, that's possible, but are there practical cases where a version in testing is higher than in sid? Well, there might be reasons to push older versions in and it might happen. However my use case is a *defined* reasonable ordering when listing versions of releases (no matter what exact version the package has - but you should always find the releases listed in the same sequence). A sequence of <past releases> - <testing> - <unstable> makes definitely sense. > Andreas: can you please give an use case where > sorting sid vs experimental is needed? My idea was primarily not about sorting package versions but rather to list releases in a determined sequence. Listing "experimental" in the end sounded reasonable to me. I admit that the versions of packages inside experimental do not necessarily follow this ordering. My application is the "Versions and Archs" button on the tasks pages and I'm just seeking a way to make sure that we do not get something like http://debian-med.alioth.debian.org/tasks/bio.en.html#seaview If you move the mouse cursor on the Button "Newer upstream" you see a sequence "sid - squeeze - etch - lenny" which is just unlogically. So any determinable sequence which includes experimental is fine. > After that convincing example, I'd vote for an extra column which will > be used to totally order unreleased suite, that would preserve the > ability to filter out non-release suites. (Yes, you can do that also > filtering out future dates, but that sounds incredibly like not the > right thing to do, at least in my eyes.) So I try to reiterate CREATE TABLE releases ( release text, /* keep name column as in other tables */ releasedate date, sort int, PRIMARY KEY (releasename) ); INSERT INTO releases VALUES ( 'etch', '2007-04-08', 400 ); INSERT INTO releases VALUES ( 'etch-security', '2007-04-09', 401 ); /* date or NULL ?? */ INSERT INTO releases VALUES ( 'etch-proposed-updates', '2007-04-10', 402 ); /* date or NULL ?? */ INSERT INTO releases VALUES ( 'lenny', '2009-02-14', 500 ); INSERT INTO releases VALUES ( 'lenny-security', '2009-02-15', 501 ); /* date or NULL ?? */ INSERT INTO releases VALUES ( 'lenny-proposed-updates', '2009-02-14', 502 ); /* date or NULL ?? */ INSERT INTO releases VALUES ( 'squeeze', NULL, 600 ); INSERT INTO releases VALUES ( 'squeeze-security', NULL, 601 ); INSERT INTO releases VALUES ( 'squeeze-proposed-updates', NULL, 602 ); INSERT INTO releases VALUES ( 'sid', NULL, 100000 ); INSERT INTO releases VALUES ( 'experimental', NULL, 100001 ); Any other comments are welcome Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
