----- Original Message -----
> From: "Federico Simoncelli" <fsimo...@redhat.com>
> To: ki...@redhat.com
> Cc: ee...@redhat.com, email@example.com
> Sent: Tuesday, July 2, 2013 10:13:25 PM
> Subject: Re: [vdsm] vdsm - closer to open source versioning and release cycle
> ----- Original Message -----
> > From: "Kiril Nesenko" <ki...@redhat.com>
> > To: firstname.lastname@example.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  merged. We should start acting
> > like a normal open source project and upstream should not be distro
> > oriented
> > !
> >  http://gerrit.ovirt.org/#/c/12448/
>  is unrelated to being open source or being distro oriented.
> Just to summarize the patch , 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).
Which is perfectly ok, as you do work toward this version and you release
tarballs/rpms/debs with pre-release signature.
> 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 .
> 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 .
> 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.
Leading the way != correct nor easy to maintain.
It may be because lack of knowledge or care.
> vdsm-devel mailing list
vdsm-devel mailing list