view .gitlab/issue_templates/new-version.md @ 6935:954d7ea5cd67 stable tip

stack: when stack base is obsolete, pick any successor, even if at random

There are situations when s0 is obsolete and we also cannot pick just one
successor for it to use in stack. In such a case, let's pick the "latest"
successor from the first set.

We're assuming that obsutil.successorssets() returns data in the same order (it
should, since it makes sure to sort data internally). Keeping that in mind,
while the successor picked for s0 by this code is not based on any sort of
sophisticated logic, it should nonetheless be the same every time.

This patch is probably not going to completely break anything that was
previously working fine, because the previous behavior was to just abort with
an exception.

This is the actual check list for releasing evolve version X.Y.Z

More details in the [README.rst file](README.rst#L219).

Preparation

* [ ] merges with compatibility branches
* [ ] compatibility tests are happy
* [ ] update `testedwith` field
* [ ] make sure CHANGELOG is up-to-date
* [ ] [prepare an announcement for the list/website](https://mypads.framapad.org/p/evolution-announce-iswcp7qx)
* [ ] sanity check install and sdist targets of setup.py

Releasing

* [ ] add the current date to CHANGELOG
* [ ] update the `__version__` field of all relevant extensions
* [ ] create a new Debian entry
* [ ] tag the version
* [ ] move the `@` bookmark to the new tag
* [ ] push/publish the tag to the main repository
* [ ] upload the tarball to PyPI
* [ ] build .deb on Heptapod CI for the tagged commit
* [ ] add `.dev0` to the `__version__` field
* [ ] merge stable into default
* [ ] push the result to https://repo.mercurial-scm.org/evolve/
* [ ] send the announcement by email to [e-mail]
* [ ] send the announcement by email to [e-mail]
* [ ] publish the announcement as a blog on https://octobus.net/blog/
* [ ] update #hg-evolve topic
* [ ] tweet about it
* [ ] toot about it