Re: [vdsm] vdsm - closer to open source versioning and release cycle
HI all, On 07/02/2013 09:17 PM, Alon Bar-Lev wrote: From: Federico Simoncelli fsimo...@redhat.com From: Kiril Nesenko ki...@redhat.com 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. I agree with Federico - this is a distinct issue. If the patch were removing a dependency on the way a certain distro did something, then the comment would be correct. 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. Release version naming is, mostly, not that big a deal. The important thing is the management of user expectations. - You don't want people to think that they're getting stable software when installing a 4.10.3-alpha package (or whatever) - You don't want people pulling the 4.10 branch to be under the impression that they are getting a stable release branch if in fact they are getting a development branch I think the version numbering/naming is less important than branch naming in this situation. The development should happen on feature branches, merged into master. Branches should only be created for a release when it is in pre-release stabilisation (so, after feature API freeze). Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ 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-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
