On 5/7/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
Seems to me that the more we work on the various 2.x trees (2.0.x, 2.2.x and trunk), the harder it becomes to get the various correct CHANGES entries in sync... For example, the CHANGES for 2.2 and trunk just refer to changes up to 2.0.56... What's the best way of syncing these? Should we stop having a single CHANGES that tries to merge all development together? Why not have something like:o Apache 1.3.x: CHANGES stay as is o Apache 2.0.x: CHANGES just incorporates 2.0.x work and we can either URL refer to older changes at the bottom of the file or, when we release, merge them. o Apache 2.2.x: CHANGES just notes 2.2.x work and we either refer to 2.0.x CHANGES and 1.3.x CHANGES or auto-merge when we release. o ....: Same pattern... Comments? Ideas?
+1 for having the CHANGES file be local to the branch and stop trying to keep them in sync. For example, what I'd say is that when we have something in trunk and it gets merged to the current stable release, it just gets removed from the trunk's CHANGES altogether. Furthermore, at the end of the 2.2.x CHANGES file, it should point at a URL or something for 2.0.x CHANGES. 2.0.x CHANGES at the end can point to a URL for 1.3.x CHANGES...(I wouldn't touch 1.3.x CHANGES, but it's unlikely we'd do many more releases for that.) I also doubt that many users are optimistic to read a 650KB+ file of CHANGES (!!!!!). I think those doing anthropology studies or are voyeurs can learn how to use Subversion to follow the history. Most folks, at best, would only want to know what's up since the prior minor release (2.0->2.2->2.4). Plus, it's a good way to slim down our checkouts - yay! -- justin
