Open Stack

On Tue, 2018-01-09 at 10:25 +0100, Gaetan wrote:
> Hello
> 
> I have submitted this patch ([1]) that add support for v_version in
> PBR. Basically I can tag v1.0.0 instead of 1.0.0 to release 1.0.0.
> 
> However, after rework it appears PBR does not behaves well, even if
> the unit tests pass:
> On tag for instance v1.0.0, the result packages in named
> `<mypackagename>-1.0.0.dev1`.
> 
> Do you know where I need to hack PBR to fix it?

So 'pbr' correctly parses the prefixed tags, but it's just the output
packages (sdists, wheels) that always unversioned? If so, this sounds
correct. Python packaging, as defined in PEP-440 [1], doesn't use the
'v' prefixes, so it doesn't really make sense to stick them in here.
Out of curiosity, what's your rationale for modifying the package name?

> Second point, to go to the end of the logic of my change, I would
> like to propose an optional way (in setup.cfg?) to **prevent** any
> tag without the 'v' prefix, ie, where a bare version tag like `1.0.0`
> is not to be considered as a valid version.
> That way, on system such as gitlab or github:
> - repository owners "protect" tags with pattern "v*", ie, all tags
> for release such as "v1.0.0", ... cannot be pushed by anyone but the
> owners/masters
> - other developer can still push other tags for other purpose

So this could be used to prevent pbr reading the tags, but it won't
stop anyone from creating them in the first place (i.e. "protect"
tags). We can do this but it would be a separate feature and, to be
honest, I'd suggest using Git hooks or some form of access control as a
better way to do this (Note: it seems GitLab already supports something
similar [2]).

Stephen

[1] https://www.python.org/dev/peps/pep-0440/
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/18471