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. 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 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). But it's fine to compare with OpenStack projects as we are now following quite their package rules. Cédric 2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) <[email protected]>: > 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 <[email protected]> > Date: Monday, September 11, 2017 at 1:38 PM > To: "Alec Hothan (ahothan)" <[email protected]> > Cc: "Beierl, Mark" <[email protected]>, Alexandru Avadanii > <[email protected]>, opnfv-project-leads > <[email protected]>, "[email protected]" > <[email protected]>, Fatih Degirmenci > <[email protected]> > > > 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) <[email protected]>: > > > > > > 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: <[email protected]> on behalf of "Beierl, > > Mark" <[email protected]> > > Date: Monday, September 11, 2017 at 6:31 AM > > To: Alexandru Avadanii <[email protected]> > > Cc: opnfv-project-leads <[email protected]>, Cedric > > OLLIVIER <[email protected]>, "[email protected]" > > <[email protected]> > > 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 > > > > [email protected] > > > > > > > > On Sep 11, 2017, at 09:26, Alexandru Avadanii <[email protected]> > > wrote: > > > > > > > > Hi, > > How about tagging releng, without branching it? > > > > Alex > > > > > > -----Original Message----- > > From: [email protected] [mailto:opnfv-tech-discuss- > > [email protected]] 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 <[email protected]>: > > > > 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 > > <[email protected]> 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: [email protected] > > Skype: davidjmcbride1 > > IRC: dmcbride > > > > > > > > > > > > -- > > David McBride > > Release Manager, OPNFV > > Mobile: +1.805.276.8018 > > Email/Google Talk: [email protected] > > Skype: davidjmcbride1 > > IRC: dmcbride > > > > _______________________________________________ > > opnfv-tech-discuss mailing list > > [email protected] > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > _______________________________________________ > > opnfv-tech-discuss mailing list > > [email protected] > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > _______________________________________________ > > opnfv-tech-discuss mailing list > > [email protected] > > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > > > > > > > _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
