Add NEWS file to track changes across versions #6250

joshua-stone · 2023-10-19T19:19:07Z

Please do not forget to update the mmex.pot file and write information about the fixed bug in the prerelease page.

This will help address the version mismatch issue pointed out in #6246

This change is

joshua-stone · 2023-10-19T19:21:05Z

@whalley This can be the start of having a single source-of-truth from where builds derive version information as well as let us prepare release notes ahead of time.

whalley · 2023-10-19T20:32:51Z

@whalley This can be the start of having a single source-of-truth from where builds derive version information as well as let us prepare release notes ahead of time.

We already have the single source of truth in the CMakeLists file....

Also release notes are held against each release in GitHub https://github.com/moneymanagerex/moneymanagerex/releases

So this file is actually a duplicate of information we already have. As I have noted before, if we need this for Flathub then we should generate it from the existing info.

joshua-stone · 2023-10-19T21:56:43Z

@whalley This can be the start of having a single source-of-truth from where builds derive version information as well as let us prepare release notes ahead of time.

We already have the single source of truth in the CMakeLists file....

@whalley This can be the start of having a single source-of-truth from where builds derive version information as well as let us prepare release notes ahead of time.

We already have the single source of truth in the CMakeLists file....

Also release notes are held against each release in GitHub https://github.com/moneymanagerex/moneymanagerex/releases

So this file is actually a duplicate of information we already have. As I have noted before, if we need this for Flathub then we should generate it from the existing info.

The point of this change is to shift to using a machine-readable format as a single source of truth so that the rest of the tools can easily consume it. The changes include having CMakeLists generate version info from the NEWS file.

As for release notes against each release on Github, the formatting has changed over time and hasn't been consistent. For example, the latest release there isn't even a handwritten changelog:

https://github.com/moneymanagerex/moneymanagerex/releases/tag/v1.6.4

By writting release information in the NEWS file, you can simply copy notes into the release notes for a tagged Github release on the releases page while making sure the notes are formatted neatly.

whalley · 2023-10-19T22:49:53Z

The existing CMAKE numbering has rigid structure for identifying the beta/alpha/rc releases where the NEWS.md file does not. I'm just a little concerned about changing the process we use for identifying build numbers and publishing the release notes. Yes, the last release notes just linked to the Issue list for that release but that seems sufficient.

We have scare resource to maintain the product as it is and wanted to avoid intoroducing some additonal maintenance with new releases. I'll let others comment further.

joshua-stone · 2023-10-20T01:52:13Z

The existing CMAKE numbering has rigid structure for identifying the beta/alpha/rc releases where the NEWS.md file does not. I'm just a little concerned about changing the process we use for identifying build numbers and publishing the release notes. Yes, the last release notes just linked to the Issue list for that release but that seems sufficient.

We have scare resource to maintain the product as it is and wanted to avoid intoroducing some additonal maintenance with new releases. I'll let others comment further.

The NEWS format might be more free-form than CMakeLists, but that doesn't mean it's without structure. The appstreamcli utility will still fail if it detects malformed input, which is something you'd want to discover early during the development process:

$ cmake ..
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Checking for one of the modules 'libcurl'
-- Found CURL: /usr/lib64/libcurl.so (found version "8.0.1")
-- Module support is disabled.
-- Version: 8.1.1
-- Build type: 
-- CXX_STANDARD: 11
-- Required features: cxx_variadic_templates
-- Found RapidJSON: /var/home/jstone/Work/github/joshua-stone/moneymanagerex/3rd/rapidjson/include
-- Could NOT find Lua (missing: LUA_LIBRARIES LUA_INCLUDE_DIR) 
Unable to parse NEWS header 'Versiion 1.7.0
~~~~~~~~~~~~~
Released: 2023-10-19': Unable to find version in: Versiion 1.7.0
~~~~~~~~~~~~~
Released: 2023-10-19
CMake Error at CMakeLists.txt:648 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 1"



-- Configuring incomplete, errors occurred!

It's simply easier for humans to update a text file so that tools can know where to look for generating output:

https://gist.github.com/joshua-stone/506800597626d0a9705fe0feade32211

I understand that this may seem like extra work for a new release, but the recurring issue we've had is syncing up version information across files because the metainfo file doesn't stay up to date, which is what this change is intended to address.

Updating a NEWS file and using it as a single source-of-truth seems like the best option here for ensuring that release information isn't duplicated or out of date.

…rectory

whalley · 2023-10-20T16:35:36Z

Alpha/Beta/RC releases have versions.

E.g
1.7.0 Beta 1
1.7.0 Beta 2

joshua-stone · 2023-10-20T19:16:44Z

Alpha/Beta/RC releases have versions.

E.g 1.7.0 Beta 1 1.7.0 Beta 2

It should follow sem-ver more closely now:

$ cmake ..
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Build type: Beta
-- Checking for one of the modules 'libcurl'
-- Found CURL: /usr/lib64/libcurl.so (found version "8.0.1")
-- Module support is disabled.
-- Version: 8.1.1
-- Build type: 
-- CXX_STANDARD: 11
-- Required features: cxx_variadic_templates
-- Found RapidJSON: /var/home/jstone/Work/github/joshua-stone/moneymanagerex/3rd/rapidjson/include
-- Could NOT find Lua (missing: LUA_LIBRARIES LUA_INCLUDE_DIR) 
CMake Warning at CMakeLists.txt:778 (message):
  Unknown Linux distribution - generating generic package.


-- 
-- MMEX configuration summary
-- ==========================
-- Version        : 1.7.0-Beta.1
-- Commit         : 253f9721d (2023-10-20)
-- Branch         : news-file
-- Host system    : Linux x86_64
-- Target system  : Linux x86_64
-- Build types    : 
-- Generator      : Unix Makefiles
-- Install prefix : /usr/local
-- DB encryption  : ON
-- 
-- Versions
-- --========--
-- Linux 6.5.6-200.fc38.x86_64
-- Fedora Linux.38 (Container Image)
-- 
-- CMake 3.27.7
-- GNU Make 4.4
-- ccache
-- GNU 13.2.1
-- wxWidgets 3.2.2
-- wxSQLite3 4.9.1
-- Lua 5.3.5
-- curl 8.0.1
-- gettext 0.21.1
-- ------------------ 8< -----------------
-- Configuring done (0.6s)
-- Generating done (0.0s)
-- Build files have been written to: /var/home/jstone/Work/github/joshua-stone/moneymanagerex/build

whalley · 2023-10-21T16:21:17Z

One, probably, final question.

What date should be reflected in the NEWS file for development/beta releases? E.g. 1.7.0 Beta 1 will be regularly updated as we merge commits. At present it would likely by updated with the date when we first named the Beta 1 release.

joshua-stone · 2023-10-21T17:15:49Z

One, probably, final question.

What date should be reflected in the NEWS file for development/beta releases? E.g. 1.7.0 Beta 1 will be regularly updated as we merge commits. At present it would likely by updated with the date when we first named the Beta 1 release.

I think what date to pick for a given release depends on the type of release. i.e., it can either reflect the time of branching a development release or the time of tagging a new stable release. Frequently updating the date string for a development cycle wouldn't be very useful since the point of a date string is to track a point in time and the changes that've been made since that point.

In the case of Version 1.7.0 Beta 1, I picked 2023-10-19 as the date because that just happened to reflect the date at the time of this PR. I can change it to an earlier point in time to be in sync with MMEX's development cycle.

For example, a Beta release would have the time that development started, which gets more notes added to it as time goes on:

Version 1.7.0 Beta 1
~~~~~~~~~~~~~~~~
Released: 2023-10-19

Bugfixes:
* Fix 1
* Fix 2

.. Eventually having:

Version 1.7.0 Beta 1
~~~~~~~~~~~~~~~~
Released: 2023-10-19

Bugfixes:
* Fix 1
* Fix 2
* Fix 3
* Fix 4

And right before it comes time to tag a new release, make sure to update NEWS with a version entry that reflects the tagged version on Github:

Version 1.7.0
~~~~~~~~~~~
Released: 2023-10-21

Does that make sense?

…WS file

whalley · 2023-10-21T19:53:18Z

Yes fair enough...

joshua-stone · 2023-10-21T20:15:08Z

Ultimately I think how MMEX team wants to update the NEWS file is going to be a matter of preference, but I think having a file dedicated to storing a history of release versions, release types, release dates, and release changes is going to be more flexible than periodically incrementing a few hardcoded values in CMakeLists.txt. It also gives contributors the opportunity to prepare release notes like how they can update README.md.

Are there any changes I should make here?

joshua-stone · 2023-10-22T00:37:47Z

Looks like these changes built successfully:

$ flatpak info org.moneymanagerex.MMEX//master

MMEX Money Manager - Organize finances and track cash flow

          ID: org.moneymanagerex.MMEX
         Ref: app/org.moneymanagerex.MMEX/x86_64/master
        Arch: x86_64
      Branch: master
     Version: 1.7.0 Beta 1
     License: GPL-2.0-only
      Origin: mmex-origin
  Collection: 
Installation: system
   Installed: 39.1 MB
     Runtime: org.gnome.Platform/x86_64/45
         Sdk: org.gnome.Sdk/x86_64/45

      Commit: 83d06d74061578b159ca8a9502fa511848747f65701989beb3a6ca5c8cf441ba
     Subject: Export org.moneymanagerex.MMEX
        Date: 2023-10-21 23:01:52 +0000

joshua-stone · 2023-10-22T00:38:14Z

Thank you for merging!

Add NEWS file to track changes across versions

bdfeb86

joshua-stone force-pushed the news-file branch from bd721d2 to bdfeb86 Compare October 19, 2023 19:23

Have CMakeLists.txt derive version from NEWS file

5ecbe63

joshua-stone added 2 commits October 19, 2023 21:13

Generate release info inside metainfo from NEWS

c5158e0

Have appstreamcli failures be fatal

32a3c76

Try to generate appstream within build directory instead of source di…

c69799f

…rectory

joshua-stone marked this pull request as ready for review October 20, 2023 02:14

Have build type be determined by version suffix in NEWS file

94c45d8

joshua-stone force-pushed the news-file branch from 4c74bc7 to 94c45d8 Compare October 20, 2023 15:16

Have NEWS and CMakeLists.txt follow sem-ver more closely

480e8ea

joshua-stone force-pushed the news-file branch from 253f972 to 480e8ea Compare October 20, 2023 19:30

Make version regex more restrictive and fix formatting slightly in NE…

4f1dad3

…WS file

whalley merged commit dd57f95 into moneymanagerex:master Oct 21, 2023
2 checks passed

joshua-stone deleted the news-file branch October 22, 2023 00:33

joshua-stone restored the news-file branch October 22, 2023 16:32

joshua-stone deleted the news-file branch October 25, 2023 17:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add NEWS file to track changes across versions #6250

Add NEWS file to track changes across versions #6250

joshua-stone commented Oct 19, 2023 •

edited by guanlisheng

Loading

joshua-stone commented Oct 19, 2023 •

edited

Loading

whalley commented Oct 19, 2023 •

edited

Loading

joshua-stone commented Oct 19, 2023 •

edited

Loading

whalley commented Oct 19, 2023

joshua-stone commented Oct 20, 2023 •

edited

Loading

whalley commented Oct 20, 2023 •

edited

Loading

joshua-stone commented Oct 20, 2023 •

edited

Loading

whalley commented Oct 21, 2023

joshua-stone commented Oct 21, 2023 •

edited

Loading

whalley commented Oct 21, 2023

joshua-stone commented Oct 21, 2023

joshua-stone commented Oct 22, 2023 •

edited

Loading

joshua-stone commented Oct 22, 2023 •

edited

Loading

Add NEWS file to track changes across versions #6250

Add NEWS file to track changes across versions #6250

Conversation

joshua-stone commented Oct 19, 2023 • edited by guanlisheng Loading

joshua-stone commented Oct 19, 2023 • edited Loading

whalley commented Oct 19, 2023 • edited Loading

joshua-stone commented Oct 19, 2023 • edited Loading

whalley commented Oct 19, 2023

joshua-stone commented Oct 20, 2023 • edited Loading

whalley commented Oct 20, 2023 • edited Loading

joshua-stone commented Oct 20, 2023 • edited Loading

whalley commented Oct 21, 2023

joshua-stone commented Oct 21, 2023 • edited Loading

whalley commented Oct 21, 2023

joshua-stone commented Oct 21, 2023

joshua-stone commented Oct 22, 2023 • edited Loading

joshua-stone commented Oct 22, 2023 • edited Loading

joshua-stone commented Oct 19, 2023 •

edited by guanlisheng

Loading

joshua-stone commented Oct 19, 2023 •

edited

Loading

whalley commented Oct 19, 2023 •

edited

Loading

joshua-stone commented Oct 19, 2023 •

edited

Loading

joshua-stone commented Oct 20, 2023 •

edited

Loading

whalley commented Oct 20, 2023 •

edited

Loading

joshua-stone commented Oct 20, 2023 •

edited

Loading

joshua-stone commented Oct 21, 2023 •

edited

Loading

joshua-stone commented Oct 22, 2023 •

edited

Loading

joshua-stone commented Oct 22, 2023 •

edited

Loading