> >> Please, also ALWAYS update ChangeLog.byversion, it saves 1 hour of > >> really dumb job when making a release. > > > > The last 2 commits were really trivial bugfixes (here, a C-k, last > > time, s/submit=Appliquer/set=custom/). > > > > I agree on the principle, and will try to stick with this, but on the > > other hand, there's no need to go ClearCase-like and take 10 minutes to > > document each byte I move in the code, is it? > > No sure. But a bug that has been fixed may have been found by others > persons. And they should be able to rely on the ChangeLog.byversion to > know if the bug they noticed was fixed or not.
What is ChangeLog.byversion for, actually? I though of it as a kind of NEWS file, ie non-trivial changes of interest for end users. To check if my bug was fixed, I'd point people to ChangeLog. Now maybe you consider this bug is a non-trivial one of interest for end users, in which case I'll document it. If ChangeLog.byversion is just ChangeLog ordered a bit differently, I would vote for adding commits with message "Released version 1.0.x" in ChangeLog, scrap ChangeLog.byversion and avoid duplicating information. -- Sylvain _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
