Hi folks, I've restructured the CHANGELOG this morning.
We now have a main CHANGELOG for the respective minor version, collecting all micro releases, and CHANGELOG-x.y files for previous versions, containing micro versions that have been released(!).
The motivation behind this was that it has become increasingly difficult for users to understand exactly which changes were in which release. Consider the following:
- 0.11.4 released 2008-08-01 - 1.0.0beta1 released 2008-08-10 - 1.0.0beta2 released 2008-08-20 - 0.11.5 released 2008-08-25Now... which of the changes made to 0.11.5 are in which 1.0.0 beta? Besides the fact that they're simply not visible (one had to scroll down to the 0.11.x entries), there is no indication whether or not any of the changes listed for 0.11 were merged at all, or when.
It now works like this: - whenever a change is made, it is put into the respective changelog.- if that change is merged to another version branch, then it is put into that version's main changelog file - changes are merged to other version branches right away (a conflict in CHANGELOG will occur, obviously, so there's no way to forget porting the changelog entry :)) - once a release in an "old" branch has been tagged (e.g. 0.11.6), the entire version info for this release is added to the respective "historical" CHANGELOG-x.y file (e.g. CHANGELOG-0.11) in the newer branches (e.g. 1.0)
I will adjust the RELEASE_NOTES in the same way later. Greetings, - David
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Agavi Dev Mailing List [email protected] http://lists.agavi.org/mailman/listinfo/dev
