Re: CHANGES file for 1.3 and 2.x
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
CHANGES file for 1.3 and 2.x
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?
Re: CHANGES file for 1.3 and 2.x
On 05/07/2007 05:38 PM, Jim Jagielski 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? I do not think that we need to merge the files. Having pointers to the other files seems to be sufficient for me. This still leaves the task of syncing the CHANGES files of the stable branches with that of the trunk which still leaves enough room for getting out of sync. So having some sort of auto-merge here would be cool. Regards Rüdiger
