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

[Simon Praetorius]

This sounds like a reasonable way:

- If something in the code (in python / c++ / buildsystem) is fixed that 
influences the user of the code whether downloaded by git, by tar.gz or 
as python package, it should be a bugfix release. This should then 
include a tar.gz package, maybe a new entry in the webpage. We should 
make the burden for this as small as possible.
- If just "metadata" is updated that is required by external 
environments, like pypi, we could add the post release suffix. There, no 
need for a long procedure is required, just a tag would be enough.


Best,
Simon


Am 26.11.21 um 09:50 schrieb Dedner, Andreas:
>
>
>       ​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 :-)
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-devel

-- 
Dr. Simon Praetorius
Technische Universität Dresden
Institute of Scientific Computing
phone: +49 351 463-34432
mail: simon.praetorius at tu-dresden.de
web: https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20211126/6c480099/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5204 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20211126/6c480099/attachment.bin>