Fair, and you are correct, pypi explicitly forbids that representation, but I think there are separable concerns here:
1) what is the Superset version? 2) how is that version represented in published artifacts across potentially multiple consuming tech stacks? I realize opinions may vary, but for the I personally would avoid coupling the two questions. Publication artifacts may include tarballs, pypi packages, npm packages, could even someday include client libs for other things like java/maven (who knows). If and when necessary, the Superset release version can be transformed in a manner that is required for specific consumers (ie you can turn 1.2.3-rc1 into 1.2.3rc1 when you push to pypi). I think there are a lot of advantages to opting into semver, in terms of existing documentation and tooling, git workflows, etc. On Wed, Mar 20, 2019 at 10:43 AM Don Bowman <d...@agilicus.com> wrote: > On Wed, 20 Mar 2019 at 13:40, Maxime Beauchemin < > maximebeauche...@gmail.com> > wrote: > > > Python's PEP-440 says otherwise: > > https://www.python.org/dev/peps/pep-0440/#pre-releases > > > > I'm not 100% on this but if I remember correctly Pypi will reject that > > specific flavor of semver-compliant string. (ie: 0.32.0-rc1) > > > > > > > This is a specific area where semver is incompatible w/ pep440 and one > should use pep440 w/ python. > https://github.com/pypa/pipenv/issues/3220 > > you can see how other projects have tried to rationalise, eg.. > https://docs.openstack.org/pbr/3.1.1/semver.html >
