----- Original Message -----
From: "Ayal Baron" abaron@redhat.com To: "Kiril Nesenko" kiril@redhat.com Cc: "Eyal Edri" eedri@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Tuesday, July 2, 2013 9:04:53 PM Subject: Re: [vdsm] vdsm - closer to open source versioning and release cycle
----- Original Message -----
Hello all,
We would like to make some changes to the vdsm project.
- 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 !
Let's sort things out here a little. Just to make sure I understand what we're talking about, are you suggesting that the 'normal' way of working is to create a version *before* there is a single line of code relevant to this version? If so, please explain what other projects (outside of ovirt) work this way. iiuc libvirt (for example) doesn't work this way. This question was also asked and ignored on the patch so let's assert that this is the way other projects actually work first before defining it as 'normal'.
In addition, the patch introduces all kinds of changes so I'm not sure which of these are what interest you and which are just getting in the way of reaching an agreement. So if you want to push this forward then please:
- explain the logic behind the naming convention
- assert that this is 'normal' and not us inventing new methods here that
are not actually accepted elsewhere. 3. split this part of the patch from the rest to be able to address each issue separately
Hello,
Let's start with the problem within current vdsm version scheme is that there is no actual release layout, vdsm-4.9.6 is release while vdsm-4.9.5 is not, this breaks expectation (of some people) of which there is a clear distinction between pre-release and release.
Expected release cycle is:
vdsm-4.9.0_alpha vdsm-4.9.0_alpha1 vdsm-4.9.0_alpha2 vdsm-4.9.0_beta vdsm-4.9.0_beta1 vdsm-4.9.0_beta2 vdsm-4.9.0_beta3 vdsm-4.9.0_rc vdsm-4.9.0_rc1 vdsm-4.9.0 vdsm-4.9.1_beta vdsm-4.9.1_rc vdsm-4.9.1
master or branch are work toward the next version, for example, if we have the following release xxx-1.0.0, then we probably have the following branches:
master - work toward next minor (1.1.0). xxx-1.0 - work toward next z for 1.0 (1.0.1).
and the following tags:
xxx-1.0.0
Once xxx.1.0.0 was released, there should be no snapshot or any build, including manual build that is <=xxx-1.0.0 from the branches, so that the sequence of upgrade will not be broken. When a beta is released out of these branches, it will be probably:
master -> xxx-1.1.0_beta xxx-1.0 -> xxx-1.0.1_beta
as these betas or of the *NEXT* version and not the previous ones.
and then when releases will be made:
master -> work toward next minor (1.2.0) xxx-1.1 -> branch of master at xxx-1.1.0 point, work toward 1.1.1. xxx-1.0 -> work toward of xxx-1.0.2
tags:
xxx-1.0.0 xxx-1.0.1 xxx-1.1.0
And so on.
Snapshots can be taken at any given point in time, in our case it can be be:
master -> xxx-1.2.0_snapshot201304051234 xxx-1.1 -> xxx-1.1.1_snapshot201304051234 xxx-1.0 -> xxx-1.1.2_snapshot201304051234
Notice that the snapshot are also a snapshot of the work toward the next version, these are not snapshots of the previous already released versions.
- We would like to see a normal branches behavior. There are a lot of
examples in [1]. (I can help with usptream releases)
I would like to use a new naming convention for builds: vdsm-<upstream-tarball>-<downstream version> For example: vdsm-4.11.0-0.1_master ... ... ... vdsm-4.11.0-0.15_beta1 vdsm-4.11.0-0.16_beta2 ... ... ... vdsm-4.11.0-0.17_rc1 <- could be shipped as GA as well vdsm is shipped vdsm-4.11.0-1 <- first z-stream build vdsm-4.11.0-2 <- second z-stream build etc.
Currently we have some projects that were moved to this style. And it
very easy to maintain the releases. Projects that were moved: ovirt-log-collector ovirt-iso-uploader ovirt-image-uploader otopi ovirt-host-deploy ovirt-engine vdsm ? <- we would like to see it here as well !
[1] http://gerrit.ovirt.org/#/c/12448/
- Kiril
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel