----- Original Message ----- > From: "Ayal Baron" <aba...@redhat.com> > To: "Kiril Nesenko" <ki...@redhat.com> > Cc: "Eyal Edri" <ee...@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. > > > > 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 > > ! > > 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: > 1. explain the logic behind the naming convention > 2. 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. > > > > > > 2. We would like to see a normal branches behavior. There are a lot of > > examples in [1]. (I can help with usptream releases) > > > > 3. 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. > > > > 4. 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 > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
