Alec, No, I'm not part of the Doctor team. I simply fix the requirements (and then packages) over the different OPNFV projects which are integrated inside Functest.
From Functest point of view, the requirements are key compared to the versioning as we are currently using git (instead of pypi) to install the packages. Stable branches (and tag in case of releng) are currently enough to build Functest stable docker images. https://git.opnfv.org/functest/tree/upper-constraints.txt https://git.opnfv.org/functest/tree/docker/core/Dockerfile You're right. I had to switch to 2017.9.0 instead of 5 due to the previous pbr conditions in Doctor setup.cfg which I have mainly defined in the other packages. I agree with tagging OPNFV release with 5.0.0 and then with removing version in setup.cfg. I set 5 in setup.cfg as default value but it can be safely removed/modified. If we select 2017.9.0, it can raise minor issues for projects which would want to release their packages in between official OPNFV releases. As the packages are not published in pypi, I don't think it's currently relevant. Cédric 2017-09-12 8:54 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>: > Hi Cedric, > > > > Inline… > > > > > > From: Cedric OLLIVIER <ollivier.ced...@gmail.com> > Date: Monday, September 11, 2017 at 10:31 PM > To: "Alec Hothan (ahothan)" <ahot...@cisco.com> > Cc: "Beierl, Mark" <mark.bei...@dell.com>, Alexandru Avadanii > <alexandru.avada...@enea.com>, opnfv-project-leads > <opnfv-project-le...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org" > <opnfv-tech-discuss@lists.opnfv.org>, Fatih Degirmenci > <fatih.degirme...@ericsson.com> > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] > stable branch window > > > > Alec, > > > > My comment simply highlighted a possible issue. > > You can simply trigger it via Doctor by setting version = 5 in its setup.cfg > > > > > > I precise doctor offers 2015.1.0 as tag. > > https://git.opnfv.org/doctor/tag/?h=2015.1.0 > > > > Then you can simply call python setup.py install or pip install . > > ValueError: git history requires a target version of > > pbr.version.SemanticVersion(2015.1.1), but target version is > > pbr.version.SemanticVersion(5.0.0) > > > > As releng/modules version is 5.0, I think the same updated tag (eg > > 2017.09) would break the rules. > > > > [Alec] > > OK I think I understand what you mean now. > > I see that the doctor git repo has quite a rocky tagging history, starting > with 2015.1.0, then using danube.3.0 notation and now having to change again > on possibly a 5.0.0 notation. > > I also see that setup.cfg currently sets the metadata version to 2017.9.0 > > I don’t want to pick on doctor project but this really shows the downside of > trying to unify an overarching integration project release (in our case > OPNFV release) and its constituents versioning. > > > > As a side note, I personally prefer to omit the version field in setup.cfg > and let pbr derive the version directly from the git tagging - but of course > this requires you can tag your versions with “2017.9.0” which indeed would > conflict with an hypothetical OPNFV “5.0.0” tag (pbr would not know which > one to pick since both are semver syntax compliant). > > > > > > > > > > When cleaning the requirements of OPNFV projects, I simply set 5 as > > default version value (all projects are free to modify that) as > > euphrates is an incorrect python package version. > > https://wiki.opnfv.org/display/functest/Requirements+management > > > > [Alec] > > How to manage dependencies across packages is an interesting and challenging > problem but I’d like to focus on the OPNFV project versioning first – and > hopefully find a good solution that works for everybody. > > > > > > By the way, I think we can hardly compare OPNFV and FD.io as the last > > one is java based (packaging and distributions are done via mvn). > > [Alec] > > Sorry I was merely pointing to the analogy of using a year and month as > versioning. > > > > But it's fine to compare with OpenStack projects as we are now > > following quite their package rules. > > > > [Alec] > > I’m not familiar yet on who does what, are you part of the doctor team? > > Would you agree to a solution that allows projects to tag their repo using > their own semver versioning (such as 2017.9.0) and tag OPNFV releases using > a prefix such as opnfv-5.0.0 (which will be conveniently ignored by pbr)? > > That is what I am trying to get to with all these emails ;-) > > I will also take it that you are not in favor of tagging OPNFV release with > “5.0.0”. > > > > > > Thanks > > > > Alec > > > > > > Cédric > > > > 2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>: > > Cedric, > > > > > > > > How to tag is a completely separate discussion and I’m actually very glad > > that you bring this up along with pbr ;-) > > > > > > > > But I’m curious why you bring up the “2017.09” example as it is not a semver > > tag and would not be recognized by pbr? > > > > For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04) > > > > OpenStack does not impose any tagging on constituent projects (that would > > cause a revolt from component owners I can guarantee that) > > > > Semver tagging has been so far always reserved to individual component > > tagging. > > > > I am currently feeling pretty uneasy with the looming E release and its > > tagging implication which could put all of us in a hole. > > > > If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and > > that should be a cause for concern for every project owner. > > > > I am sorry to repeat myself but I don’t think everyone has grasped yet the > > implication that has on how projects should version their code and how they > > can manage their artifacts starting from Euphrates. > > > > > > > > Let me clarify again, I am not questioning the lock-step versioning that is > > in effect in Euphrates but a far more damaging decision would be to tie the > > OPNFV release version to semver tagging and hijack semver tagging for the > > purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on every > > repo). > > > > > > > > I would prefer if we could keep an OPNFV prefix for the tags. That was > > perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to > > see the release name (understandably as it is redundant to the release > > version) at least keep an opnfv prefix in front of it for the tags (e.g. > > “opnfv-5.0.0”) so that project owners can version independently of the OPNFV > > release using semver compatible tags (like virtually every other open source > > project out there) > > > > > > > > > > > > Regards, > > > > > > > > Alec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Cedric OLLIVIER <ollivier.ced...@gmail.com> > > Date: Monday, September 11, 2017 at 1:38 PM > > To: "Alec Hothan (ahothan)" <ahot...@cisco.com> > > Cc: "Beierl, Mark" <mark.bei...@dell.com>, Alexandru Avadanii > > <alexandru.avada...@enea.com>, opnfv-project-leads > > <opnfv-project-le...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org" > > <opnfv-tech-discuss@lists.opnfv.org>, Fatih Degirmenci > > <fatih.degirme...@ericsson.com> > > > > > > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] > > stable branch window > > > > > > > > I think it could hurt only if you select 2017.09 as tag. > > > > I precise pbr compares version (eg 5.0) and tags then it would break > > > > the python package. > > > > > > > > Cédric > > > > > > > > 2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>: > > > > > > > > > > > > Fatih mentioned that changes in F would be in a different repo after the > > > > reorganization of the releng repo – so branching releng would technically > > > > not be needed for Euphrates? > > > > > > > > In any case, it does not hurt to tag (I was surprised tags were not used > > > > more often in OPNFV repos to mark internal versions…) > > > > > > > > > > > > > > > > > > > > > > > > Alec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: <opnfv-project-leads-boun...@lists.opnfv.org> on behalf of "Beierl, > > > > Mark" <mark.bei...@dell.com> > > > > Date: Monday, September 11, 2017 at 6:31 AM > > > > To: Alexandru Avadanii <alexandru.avada...@enea.com> > > > > Cc: opnfv-project-leads <opnfv-project-le...@lists.opnfv.org>, Cedric > > > > OLLIVIER <ollivier.ced...@gmail.com>, "opnfv-tech-discuss@lists.opnfv.org" > > > > <opnfv-tech-discuss@lists.opnfv.org> > > > > Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] > > > > stable branch window > > > > > > > > > > > > > > > > +1. Would not want changes to the opnfv-docker.sh script for F to impact > > > > building of E maintenance releases. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Mark > > > > > > > > > > > > > > > > Mark Beierl > > > > > > > > SW System Sr Principal Engineer > > > > > > > > Dell EMC | Office of the CTO > > > > > > > > mobile +1 613 314 8106 > > > > > > > > mark.bei...@dell.com > > > > > > > > > > > > > > > > On Sep 11, 2017, at 09:26, Alexandru Avadanii <alexandru.avada...@enea.com> > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > How about tagging releng, without branching it? > > > > > > > > Alex > > > > > > > > > > > > -----Original Message----- > > > > From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss- > > > > boun...@lists.opnfv.org] On Behalf Of Cedric OLLIVIER > > > > Sent: Monday, September 11, 2017 7:51 AM > > > > To: David McBride > > > > Cc: opnfv-project-leads; TECH-DISCUSS OPNFV > > > > Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window > > > > > > > > Hello, > > > > > > > > Could you please confirm that no stable/euphrates branch will be created for > > > > releng again? > > > > Else we are obliged to select a specific git commit id to build our Functest > > > > stable containers which is not the best way. > > > > I precise Functest depends on the opnfv python package which is hosted by > > > > releng (https://git.opnfv.org/releng/tree/modules). > > > > > > > > Cédric > > > > > > > > 2017-09-09 1:24 GMT+02:00 David McBride <dmcbr...@linuxfoundation.org>: > > > > > > > > Reminder... > > > > > > > > The stable branch window closes as of MS7, one week from today, on > > > > September > > > > 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready > > > > to branch. Aric will branch any projects that have not already been > > > > branched on Sept 15. > > > > > > > > Let me know if you have any questions. > > > > > > > > David > > > > > > > > On Tue, Aug 29, 2017 at 3:23 PM, David McBride > > > > <dmcbr...@linuxfoundation.org> wrote: > > > > > > > > > > > > Team, > > > > > > > > As you know, MS6 was this past Friday, Aug 25. In addition to the > > > > requirements associated with MS6, this milestone also marks the > > > > opening of the stable branch window, which subsequently ends with MS7 on > > > > > > > > Sept 15. > > > > > > > > > > > > This means that PTLs may request to branch their project any time > > > > before Sept 15. Note that I erroneously told the release meeting > > > > this morning that PTLs may create their own branch. That's not the > > > > case. Instead, please contact Aric (copied) and request that he create the > > > > > > > > branch for you. > > > > > > > > > > > > Also, as a reminder, we have changed the version number format as of > > > > the Euphrates release. > > > > > > > > 5.0.0 - Euphrates initial release version > > > > 5.1.0 - Euphrates SR1 > > > > 5.2.0 - Euphrates SR2 > > > > > > > > Let me know if you have any questions. > > > > > > > > David > > > > > > > > -- > > > > David McBride > > > > Release Manager, OPNFV > > > > Mobile: +1.805.276.8018 > > > > Email/Google Talk: dmcbr...@linuxfoundation.org > > > > Skype: davidjmcbride1 > > > > IRC: dmcbride > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > David McBride > > > > Release Manager, OPNFV > > > > Mobile: +1.805.276.8018 > > > > Email/Google Talk: dmcbr...@linuxfoundation.org > > > > Skype: davidjmcbride1 > > > > IRC: dmcbride > > > > > > > > _______________________________________________ > > > > opnfv-tech-discuss mailing list > > > > opnfv-tech-discuss@lists.opnfv.org > > > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > > > > > _______________________________________________ > > > > opnfv-tech-discuss mailing list > > > > opnfv-tech-discuss@lists.opnfv.org > > > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > > > > > _______________________________________________ > > > > opnfv-tech-discuss mailing list > > > > opnfv-tech-discuss@lists.opnfv.org > > > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > > > > > > > > > > > > > > > _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
