----- Original Message -----
> From: "Kiril Nesenko" <ki...@redhat.com>
> To: vdsm-devel@lists.fedorahosted.org
> Cc: "Eyal Edri" <ee...@redhat.com>
> Sent: Tuesday, July 2, 2013 2:30:56 PM
> Subject: [vdsm] vdsm - closer to open source versioning and release cycle
> Hello all,
> We would like to make some changes to the vdsm project.
> 1. We would like to see this [1] merged. We should start acting
> like a normal open source project and upstream should not be distro oriented
> !
> [1] http://gerrit.ovirt.org/#/c/12448/

[1] is unrelated to being open source or being distro oriented.

Just to summarize the patch [1], beside the technical details, it all comes
down to change the release cycle bumping the version at the beginning of the
development cycle.

This might be common in java projects (and their tailored build systems
as maven) but it's rather unconventional in python and in any other open
source project that vdsm is relying upon, e.g. libvirt, qemu, etc.

Bumping the version early (at the beginning of the development cycle)
means that you are generating tarballs/rpms/debs/etc... advertising a version
that is not released/finalized or complete (e.g. missing APIs).

On the contrary it's common practice to bump the version only at the
end of the development cycle (beta/rc) when the features/API are finalized.

We might say that master builds are for developers only so we don't care
if these builds are exposing a misleading version (even though I personally
care), but I still don't see what we gain with [1].

I assume that if you're proposing this change it means that you're facing one
or more technical issues that you think they may be fixed using [1].
If you could mention them I think we'll be able to find a solution without
changing the versioning. After all there are plenty of other successful open
source projects leading the way.

vdsm-devel mailing list

Reply via email to