Guillaume Munch wrote: > Le 26/05/2016 07:45, Jean-Marc Lasgouttes a écrit : > >> Time to think about the release date of 2.3.0 now ;) >> > > Yes, let's have this discussion :) > > I find the interval between feature releases too high. Having an > interval longer than one year (more than two for 2.2) means that some > features are left untested for more than a year, as we saw for some bug > fixes for 2.2.
I believe we all agree that we need to release more often, but there are quite different opinions how to achieve that goal. > Changes should be tested more regularly, not all at once every two > years. So one could have a fixed release interval of one year. Meeting > the deadline would be more important than being full of features. > > The schedule could be decided in advance, and be on the website for > clarity. We need to decide: Either have a fixed schedule, and an unknown feature set of the next release, or a fixed feature set, and an unknown schedule. We do not have enough man power for defining both a fixed feature set and a fixed release schedule. > One could branch at feature and string freeze, between alpha and beta. > This avoids having a master branch closed for so long. > > All the above suggestions are compatible with the numbering system > described at http://www.lyx.org/VersioningSystem. > > In addition I would suggest the following: (Officially) allow new > features that do not require a file format change into minor releases. > > The main reason is again that this allows testing more regularly. For > instance, in my case, I can use a development version in my work, but > only if the file format is the same. Unfortunately it also means we force all users to test these new features. --- IMO, the key point to more frequent releases is automation. There are many things that are currently done manually which can be automated: - Automate windows installer generation. This would probably mean to switch to mingw, since we can do both a mingw build and run nsis from a linux machine. - Have a build server that does automatic builds on a regular basis for all three platforms (Linux, OS X, windows) and makes binary packages and build logs available. - Run tests automatically, using the binaries from the build server, make test results available. - (not related to automation) Disentangle unrelated stuff from the release. For example, the current way of updating the documentation is inefficient. In agile software development you write the documentation of a new feature almost at the same time as you implement the fetaure (this is one of the good aspects of agile software development). If we do that as well we can get rid of a noticeable delay at release time. Also, there is no reason why the third-party parts of the windows installer need to be updated when a release is done. This can be desynchronized as well to avoid delays. - (not related to automation) Set bug targets more realistically. This avoids massive retargeting (with related discussions), and gives a better picture what needs to be done for the release. Georg
