GNOME Bugzilla – Bug 623040
Add release_datetime field to GstPluginDesc
Last modified: 2010-07-23 20:30:48 UTC
Created attachment 164811 [details] [review] plugin: add release datetime field to GstPluginDesc and set it if GST_PACKAGE_RELEASE_DATETIME is defined It would be nice if plugins had some kind of date/time info that indicates in absolute time what API/ABI/release version they're dealing with. Module version numbers are not very useful for comparisons across different modules or to ensure that a plugin is at least a certain version. Attached patch adds an optional release_datetime field to GstPluginDesc, which can be set by defining a certain preprocessor macro. In GStreamer modules, this would either be set to the current date and time in case of git/prerelease, or the date of the release, extracted from the .doap file if it's a release.
Created attachment 164812 [details] [review] binaryregistry: save and load datetime from GstPluginDesc
Created attachment 164813 [details] [review] configure: use new AG_GST_SET_PACKAGE_RELEASE_DATETIME_WITH_NANO macro (see below for the common patch with the .m4 for this will)
Created attachment 164814 [details] [review] common: add AG_GST_SET_PACKAGE_RELEASE_DATETIME* m4 macros
Created attachment 164815 [details] [review] elementfactory: allow core to pre-empt gst_element_register() Make gst_element_register() call into core before actually registering an element factory. This will come in handy in future to prevent registration of factories, e.g. when an element has moved to a different module or plugin. This is just to get an idea what could be done to use this this later on (only given certain conditions and making certain assumptions about plugin loading which may not always be true currently, but that's beside the point.)
Is there a reason why we use a string instead of a guint64 unix timestamp? I'm not sure which one is simpler to do, but we don't get parsing issues when using a number.
In the first iteration of this patch I actually used a simple integer (decimal number YYYYMMDDHH). I also considered using unix timestamps, but those are not very nice to deal with in configure.ac and Makefiles, e.g. when hard-coding a date (as some external projects may want to do) or trying to convert the date string from the .doap file into a suitable value. In the end I just thought it was all very silly and the right thing to do was to go for a string in a well-defined and easy-to-parse format. I don't think there's a parsing "issue" (we can always replace the checking function with a 1-line sscanf if it bugs you, or skip the check altogether for now). While it would be nice if we could use the glib function mentioned in the code, I also felt adding seconds to the time format was overdoing it a little. We could probably get away without any time even, but I felt it should be there for completeness (and same-day brown-paperbag releases etc.).
Makes sense. +1 from me.
common: commit 2004d03037bbb2bb72de7a49ba501a7b5f6e2f92 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Mon Jun 21 16:26:21 2010 +0100 Add AG_GST_SET_PACKAGE_RELEASE_DATETIME and _DATETIME_WITH_NANO macros for configure Sets GST_PACKAGE_RELEASE_DATETIME, either to the current date and time, or to the specified datetime, or to the date of the current release based on the .doap file. In a GStreamer module context, one could use it like this: AG_GST_SET_PACKAGE_RELEASE_DATETIME_WITH_NANO([$PACKAGE_VERSION_NANO], ["${srcdir}/$PACKAGE.doap"], [$PACKAGE_VERSION_MAJOR.$PACKAGE_VERSION_MINOR.$PACKAGE_VERSION_MICRO]) https://bugzilla.gnome.org/show_bug.cgi?id=623040 core: commit 708bc7dc97ba4c2c8659820fc2bdf0b1e6bab767 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Fri Jul 23 20:46:10 2010 +0100 tools: make gst-inspect print the release date time stamp commit bf3582b9c426f943588d4d26b70358af8751fbda Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Mon Jun 21 17:34:49 2010 +0100 configure: use new AG_GST_SET_PACKAGE_RELEASE_DATETIME_WITH_NANO macro commit 042e0567766c979c63af0c5082d70bea9c924693 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Sun Jun 20 01:55:00 2010 +0100 binaryregistry: save and load release date time in GstPluginDesc https://bugzilla.gnome.org/show_bug.cgi?id=623040 commit 8c72758ec241aeb8d401b26515ac66be19737efb Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Sun Jun 20 00:33:36 2010 +0100 plugin: add release datetime field to GstPluginDesc and set it if GST_PACKAGE_RELEASE_DATETIME is defined This is a string describing a date and/or date/time in a simple subset of the ISO-8601 format, namely either "YYYY-MM-DD" or "YYYY-MM-DDTHH:MMZ" (with 'T' the date/time separator and the 'Z' indicating UTC). The main purpose of this field is to keep track of plugin and element versions on an absolute timeline, so it's possible to determine which one is newer when comparing two date time numbers. This will allow us to express 'replaces'-type relationships betweeen plugins and element factories in future, even across different modules and plugin merges or splits (source module version numbers aren't particularly useful here, since they can only meaningfully be compared within the same module). It also allows applications and libraries to reliably check that a plugin is recent enough without making assumptions about modules or module versions. We use a string here to keep things simple and clear, esp. on the build system side of things. https://bugzilla.gnome.org/show_bug.cgi?id=623040