[Spice-devel] Fixing the spice-gtk version scheme mess

[Hans de Goede]

Hi,

On 01/02/2013 11:24 AM, Marc-André Lureau wrote:
> Hi
>
> ----- Mensaje original -----
>> Hi all,
>>
>> Marc-André just did a new Fedora build fixing the
>> SSL issues we we're having with 0.15 (thanks for that),
>> but this is based on a git snapshot, and because of
>> the way our buildsys code generates git snapshot
>> tarbals is numbered 0.15
>> There are several problems with this:
>> 1. If we've a serious bug like this, we should just do
>> a new tarbal release with official announcements,
>> updating of the download page, etc. Fedora / RHEL are
>> not our only downstreams. Other distributions are
>> packaging spice-gtk too, and we should behave as a good
>> upstream for them. Doing an official  0.15.1 bugfix release
>> would clearly indicate to those other upstreams that
>> that is the version to use, rather then them having
>> to pick a random git snapshot.
>
> If we want a new release, let's just do 0.16

This is what we've been doing so far, and *it is not working*

We keep on packaging git snapshots in Fedora and RHEL left and
right, showiing this scheme is broken.

AFAIK we try to follow gnome / gtk / glib in how we deal
with most things. All of these have bugfix releases,
so has the kernel, so has spice[-server], and almost
any other free software project under the sun!

Please stop stubbornly pushing your own versioning scheme,
AFAIK others have had this same discussion with you already
and told you we need bug fix releases.

Just look in the Fedora spec-file how often we've packaged
a git snapshot to get fixes out there, that gives you
all the info you need to have.



>
> 0 is major - bump only for API break
> 16 is minor - new releases of spice-gtk
>
> For ABI break, each library (spice-gtk/glib/controller) has independent visioning.
>
>> 2. The way our "make dist" generates git snapshot tarbals,
>> makes it impossible to do a 0.15.1 release now, since
>> we now already have a 0.15.3 in Fedora.
>
> Because we don't need to with the scheme above. Each update in git is a third revision field getting bump after each commit.

We do need it, because the scheme above is *broken* !!

Adding the extra .0 is trivial and won't hurt a bit,
doing bug-fix release is really something which we *must* do,
given how often we end up adding patches post the official
release to the Fedora packages.

Regards,

Hans