Baby steps towards more frequent major releases

[Scott Kostyshak]

The last few years have been atypical, but even before then I think most
of us were in favor of more frequent major releases. I'm not going to
spend much time on this type of long-run goal, but I'm starting to think
about how to at least crawl towards it. Here are a few thoughts in no
particular order:

1. I appreciate that non-trivial bugs and features are currently being
   done on a branch, and merged with a merge commit (i.e., without
   fast-forward). It is more annoying than working directly on master,
   but I think we should do more of this even when we're not close to a
   release. It makes it easy to daily-drive master. We need to make it
   as easy as possible for at least developers to daily-drive master so
   that we can catch regressions quickly.

2. I'm removing a lot of the 2.4.0 milestones rather than "punting" them
   down to 2.5.0. This makes it easier when starting to think about a
   release to get an understanding of what should be done. We have a
   "fileformat" tag so we can use that rather than setting the
   milestone. If we need other ways to communicate that an issue should
   be done for *a* major release, but not necessarily the next one,
   let's create a new specific tag to communicate that rather than
   setting the milestone.

3. At some point, Yuriy had proposed a unit test framework. I personally
   think this could be nice for catching regressions faster.

4. I will try to work on the release scripts and automate as much as
   possible.

5. We should produce snapshot binaries (i.e., testing releases that
   aren't necessarily at a stage with criteria) more frequently. This is
   especially helpful for platform-specific bugs so we can ask the
   reporter if they can reproduce with the latest test release. We need
   to make it easy for users to try a test release without that test
   release affecting anything else on their system. i.e., if they
   install a test release, it can be used in parallel to the latest
   stable release. This might already be the case, but is it the case
   only in theory or are we confident enough to say this to users?  I
   suppose there is no way around the fact that the test release will
   change the file format so we have to make that clear to the user. The
   only alternative would be something like what Guillaume proposed,
   lyx-unstable.

Do you have any specific ideas for how we can make it easier to have
more frequent major releases?

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20221126/108c2061/attachment-0001.asc>