[Dune-devel] vX.Y.Z.alpha tags

[Markus Blatt]

Now I am totally confused about what we are talking about. Are we talking about pypi specific fixes
(like uploading a misconfigured version, etc.) or broken python stuff. I have assumed the former.

Christian, you are not correct about Debian. There might be (and usually are) code changes to DUNE
for a Debian release, such as bug fixes detected by Debian after the release. Therefore Debian will use
e.g. 2.8.0-1 as Debian package version (packaged DUNE does not see this -1 suffix), tagged as 
debian/2.8.0-1, the next uses the -2 suffix.

To be clear DUNE source tarballs/dune.module should never have a suffix! Otherwise we might break external packaging.

I was proposing something similar to Debian for pypi (use version 2.8.0-1, tag with pypi/2.8.0-1 and so on), which hides these
changing versions from everybody that is not interested in building their own pypi packages.

Of course if there are serious bugs in DUNE that warrant a new DUNE release that is a different story
and I agree that a new proper bugfix release should be done. But we might want to do this for all
modules as up to now we did not make any guarantees that 2.8.x works with 2.8.y for x=!y (or at least it was
never tested which means that it might not have worked).

Markus

On Fri, Nov 26, 2021 at 08:50:08AM +0000, Dedner, Andreas wrote:
>​I missed this from the webpage I linked in the previous email:
>Implicit post releases<https://www.python.org/dev/peps/pep-0440/#id40>
>
>Post releases allow omitting the post signifier all together. When using this form the separator MUST be - and no other form is allowed. This allows versions such as 1.0-1 to be normalized to 1.0.post1. This particular normalization MUST NOT be used in conjunction with the implicit post release number rule. In other words, 1.0- is not a valid version and it does not normalize to 1.0.post0.
>
>So 2.8.0-1 would be an allowed version number after all so that would be another option for a tag.
>________________________________
>From: Christian Engwer <christian.engwer at uni-muenster.de>
>Sent: 26 November 2021 08:48
>To: Dedner, Andreas <A.S.Dedner at warwick.ac.uk>
>Cc: Markus Blatt <markus at dr-blatt.de>; dune-devel at lists.dune-project.org <dune-devel at lists.dune-project.org>
>Subject: Re: [Dune-devel] vX.Y.Z.alpha tags
>
>> All we're asking is for a mechanism to provide upgrades to the pypi packages that allow us to tell users for are now working with a buggy package to simply run
>>    pip install --upgrade
>> to get a bugfix in the same way we would tell C++ users on the release branch to do git pull if we fixed a bug.
>> We would have preferred to have a well-defined state in the repositories to do that if possible.
>
>IMHO if the code in the dune-common is broken for a part of the
>feature set (e.g. for python bindings) and we have now a fix, this
>qualifies for a quick bug-fix release. And then also the versioning would be clear.
>
>The situation in Debian (as it was mentioned before) is different, as
>the source code it self didn't change, but the package information
>that are managed separately have changed. Thus it is not possible to
>reflect these changes in the version number of the software, but the
>package appends this infot via a '-1', '-2', etc. to the package
>version.
>
>Ciao
>Christian
>
>PS: great that dune works now via pypi! Thanks :-)

-- 

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858