Re: [vdsm] vdsm - closer to open source versioning and release cycle
- Original Message - > From: "Federico Simoncelli" > To: ki...@redhat.com > Cc: ee...@redhat.com, vdsm-devel@lists.fedorahosted.org > 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" > > To: vdsm-devel@lists.fedorahosted.org > > Cc: "Eyal Edri" > > 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). 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 [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. Leading the way != correct nor easy to maintain. It may be because lack of knowledge or care. > > -- > Federico > ___ > 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
Re: [vdsm] vdsm - closer to open source versioning and release cycle
- Original Message - > From: "Kiril Nesenko" > To: vdsm-devel@lists.fedorahosted.org > Cc: "Eyal Edri" > 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. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm - closer to open source versioning and release cycle
- Original Message - > From: "Ayal Baron" > To: "Kiril Nesenko" > Cc: "Eyal Edri" , 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-- > >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
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 > > 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-- >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] 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 ! 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-- 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
