Le 03/06/2016 13:02, Jean-Marc Lasgouttes a écrit :
Le 31/05/2016 à 22:26, Georg Baum a écrit :
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.
Yes, I think that having nightlies would be more efficient than
that.
Still, the problem with nightlies is that the stable version only has a
subset of the new features, and one cannot use the master version
because it changes the files one is working on. This is asking people,
"please test the nightly version, however, once you get in you are
locked, unless you manually convert all your files back".
Yet, most of the file format changes are very simple. I wonder whether
one could introduce a single compilation variable to disable them,
and ask developers to enclose file-format-specific code between the
corresponding #ifdefs. (For instance in my last file format change all
that was needed to be enclosed was the parsing code.) This would allow
the release of "master versions without file format changes", either as
nightlies or as official "x.5" versions as Pavel suggested by Pavel in
another message (without having to maintain three branches in parallel).
- More work for developpers
+ Less pressure on the stable maintainer to accept new features,
and less work to backport features.
+ Testable nightlies
+ Possibility for "master-without-FF" releases without a third branch to
maintain.
+ There is a program called unifdef that can get rid at each major
release of the #ifdefs from the previous version automatically.
- 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.
Do you have a particular service in mind? I agree that this would be
nifty.
- Run tests automatically, using the binaries from the build
server, make test results available.
Sure. Not difficult once we have the nightlies.
Jean-Marc, have you looked into ci.inria.fr?
- (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.
The problem is that we are not very good at writing documentation
and we let Uwe do all this. If he had a small team of documenters to
help, life would be much easier.
- (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.
We are not good at bug targets, except when the patch is almost
done. I am not sure that we can improve much on that. We cannot
force people to work on a bug, unfortunately.
It was decided that we would use .x targets instead of .1,2,3 targets,
so this is already better.
Jean-Marc, also could a new Trac version not help automating the
retargeting the release manager has to do every time? Independently,
would it not be now the time to update Trac to a newer version? (I am
assuming you are the one who knows about this.)
Guillaume
