On Sat, 22 Feb 2020 at 22:31:26, Frédéric Mangano-Tarumi wrote:
> ---> INSTALL | 4 +-> TESTING | 3 +-> alembic.ini | 86 +++++++++++++++++++++++++++++++++++++++> aurweb/initdb.py | 9 ++++> aurweb/schema.py | 8 ++++> migrations/README | 48 ++++++++++++++++++++++> migrations/env.py | 73 +++++++++++++++++++++++++++++++++> migrations/script.py.mako | 24 +++++++++++> 8 files changed, 252 insertions(+), 3 deletions(-)> create mode 100644 alembic.ini> create mode 100644 migrations/README> create mode 100644 migrations/env.py> create mode 100644 migrations/script.py.mako
Looks great, thanks! I merged this patch and the two followup patches
into the pu branch. I will do some more testing and merge them to master
if there are no issues.
We should also think about phasing out the text files in the upgrading/
subdirectory. Maybe we should simply keep them for one or two releases
and remove the directory entirely later? If anybody ever still needs
them after they have been removed, they can still be recovered from the
Git history...

Lukas Fleischer [2020-02-26 14:00:51 +0100]
> We should also think about phasing out the text files in the upgrading/> subdirectory. Maybe we should simply keep them for one or two releases> and remove the directory entirely later? If anybody ever still needs> them after they have been removed, they can still be recovered from the> Git history...
I don’t know who reads the upgrading instructions, but how about having
a 4.x.0-and-later.txt saying that SQL migrations are now handled by
Alembic, and referring to migrations/README?
Let’s also keep in mind that some upgrades might require manual
intervention anyway. In my opinion these breaking changes should be
documented in commit messages and synthesized in release notes, but
whatever the AUR team is used to should be fine too.

On Wed, 26 Feb 2020 at 22:10:09, Frédéric Mangano-Tarumi wrote:
> Lukas Fleischer [2020-02-26 14:00:51 +0100]> > We should also think about phasing out the text files in the upgrading/> > subdirectory. Maybe we should simply keep them for one or two releases> > and remove the directory entirely later? If anybody ever still needs> > them after they have been removed, they can still be recovered from the> > Git history...> > I don\u2019t know who reads the upgrading instructions, but how about having> a 4.x.0-and-later.txt saying that SQL migrations are now handled by> Alembic, and referring to migrations/README?> > Let\u2019s also keep in mind that some upgrades might require manual> intervention anyway. In my opinion these breaking changes should be> documented in commit messages and synthesized in release notes, but> whatever the AUR team is used to should be fine too.
I like that suggestion.
In the past, we did not have any release notes, except for announcement
emails sent to the mailing lists. I am not sure how easy it would be to
collect those emails, compile a CHANGES.md file and add it to the source
tree, alongside with upgrade instructions extracted from the upgrading/
subdirectory. This would allow us to get rid of the directory entirely.