Hi Helder. Helder Magalhães: > I seems like this change could have fixed visible errors so, as this > didn't go through the usual bug reporting procedure, I'd say this > NeedsReleaseNote [1]. ;-)
I don’t think we’ve used that keyword before. In fact, we don’t tend to use the keywords at all in Bugzilla for Batik. The small number of developers means we probably don’t need much process overhead. > I'm not sure if, before releasing a new version commits are throughly > analyzed, though for (potentially) missing things in "CHANGES": I've > never got to quite understood if there's a procedure for this -- I've > looked at file "MAINTAIN" but nothing relevant was found > (nevertheless, step 8 of "Distribution Creation" seems somehow > related). For the 1.6 and 1.7 releases, I went through all the commits since the previous release and updated the CHANGES file. Recently, I have been making sure to update CHANGES as I go, to avoid having to do that. It shouldn’t be hard to come up with a list of commits that didn’t touch CHANGES, and only look at those, so if CHANGES isn’t updated as fixes are checked in, I guess it’s not a big problem. > Should a similar tip (analyze commits before releasing a new > version) be added to the MAINTAIN file? I just tweaked the wording of step 8 there to say to update CHANGES before a release. -- Cameron McCormack ≝ http://mcc.id.au/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
