On Tue, May 31, 2016 at 10:26:57PM +0200, Georg Baum wrote: > 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.
I think these are all good ideas and would make the release process smoother, whether we move towards a more continuous release process or not. Scott
signature.asc
Description: PGP signature
