search

c4dm / qm-dsp

A C++ library of functions for DSP and Music Informatics purposes. Used by the QM Vamp Plugins amongst other things.
https://code.soundsoftware.ac.uk/projects/qm-dsp
GNU General Public License v2.0
52 stars 11 forks source link

clarify release-tags #5

Open umlaeute opened 4 years ago

umlaeute commented 4 years ago

Debian maintainer of the qm-dsp package here.

while updating the Debian package, i went totally confused by the versioning scheme used here.

the releases page lists the following (recentish) releases:

what are these qm-vamp-plugins-... releases? are they releases of the qm-vamp-plugins (in the qm-dsp repository)? or are they releases for the qm-vamp-plugins?

assuming the latter, i inspected the differences between qm-vamp-plugins-v1.7.1 and v1.7.1, and while the two are quite similar, they are not the same. why?

will there be a v1.8.0 release for qm-dsp?

cannam commented 4 years ago

Hi there - thanks for the query about this. The situation is that releases have happened so infrequently that no real system has ever been settled on, there is no scripted release process, and releases tend to be unplanned, often responsive to bug fixes. In fact in the time spanned by the last four releases we have also moved from Subversion to Mercurial and then to Git, as well as going from closed-source binary-only releases to source releases - so a lot about the landscape is found to have moved each time a new release happens.

One result of this is that qm-dsp has never really developed a separate release identity and a proper versioning scheme. Effectively the version in the tag (qm-vamp-plugins-v1.8.0) is both the version of qm-vamp-plugins that uses this tag of the library code, and the current version of the library, since the library has no other version associated with it. So the current version is 1.8.0, but the tag is qm-vamp-plugins-v1.8.0.

I clearly ought to go back to this and do it properly. They probably should continue to have synchronised version numbers, but qm-dsp clearly should have a proper version number as its tag. Perhaps I should even make a very minor release (say 1.8.0.1) of both, just to clear up the numbers and ensure that releasing is properly automated.

Incidentally, v1.7.1 and qm-vamp-plugins-v1.7.1 are the same code - the only difference is that the latter contains the former tag in the repo (at the time this code was kept in Mercurial, where tags are stored within the repo itself). They are two consecutive commits with nothing else in between.

umlaeute commented 4 years ago

again, from a Debian maintainer POV, i can only welcome the use of an predictable naming scheme for tags.

E.g. if all tags follow the scheme v<major>.<minor>..., this makes it easy for use to automatically track new upstream releases (as in: I get a notification whenever there's a new upstream release, and can then investigate on whether i need to prepare a new upload to Debian).

If the tag-names are unstructured (e.g. both foo-bar-1.2.3 and v1.1) it's really hard to tell machines what to look for in order to determine that there has been a new release.

dvzrv commented 4 years ago

As a package maintainer for Arch Linux I can only 2nd what @umlaeute has stated here.

Unpredictable tagging formats make it really hard for package maintainers to track upstreams.