I would like to propose, that following Release 8 of Bloodhound, we start developing against Trac 1.0-stable rather than waiting for minor releases of Trac before upgrading (e.g. Trac 1.0.2). I propose that we frequently merge changes from Trac 1.0-stable to our copy of Trac.
To give provide some immediate justification for why this would be beneficial, consider the changes on-going in #695 [1]. In #695 it has been proposed to port at least 3 changes to Trac, and those changes are being integrated into Trac in #11440 [2]. The current situation is, in order to close #695 for Release 8 we will end up patching our copy of Trac, and then we must roll-back those changes (or resolve merge conflicts) when Trac 1.0.2 is merged into . At that point, we need to do additional testing, and it will likely be some time since the changes have been implemented in Bloodhound so the changes won't be as fresh in our minds. All of this leads to a more time-consuming and error-prone situation. If we move to developing from 1.0-stable, we can push changes to Trac and immediately merge them back into Bloodhound. A few concerns may come to mind, such as how stable is Trac 1.0-stable? In my experience, it is very stable. The Trac developers stage proposed changes for code-review rather than immediately pushing the changes, which leads to fewer defects on the stable branches. I can only think of a few situations in which a regression was introduced, and in almost all of those cases the issue was caught and fixed within a few days. Another concern could be that the major releases of Bloodhound should be based on an official release of Trac. It has previously been proposed that Trac would aim for a shorter release cycle, and I raised this again recently, with the suggestion that we aim for a 3 month release cycle [3]. A shorter release cycle for Trac will allow us, with some planning, to align the Bloodhound releases with those of Trac. The more frequent release cycle may be possible once a few of the newer Trac developers are brought up to speed on how to do the release management. In a previous email [4], I mentioned that I planned to do work in Release 9 or Release 10 to integrate changes from Trac 1.0.2. In addition to merging in the Trac codebase, changes to the Trac templates and CSS that we wish to mirror in Bloodhound usually require manual edits to the BloodhoundTheme templates. Trac 1.0.2 has turned out to be a fairly big milestone in terms of number of fixes and minor enhancements. The number of tickets closed will be 147 [4] by the end of the week, and since there isn't yet a definite date for the release, it could grow larger. I've been creating tickets in Bloodhound for changes that will be needed to keep pace with Trac. For the Trac 1.0.2 release, the tickets are tagged with trac-1.0.2 [6], and there is a "master ticket" [7]. This is a lot of changes, and it will take weeks to integrate them all. As mentioned, it would have been faster to make these changes in Bloodhound concurrent with the changes that I made to Trac. Therefore I think it will be more efficient in the future to have a shorter integration cycle. Please let me know if you have any thoughts or concerns. [1] http://issues.apache.org/bloodhound/ticket/695 [2] http://trac.edgewall.org/ticket/11440 [3] https://groups.google.com/d/msg/trac-dev/l5YuG7DysOE/sAEQeSufJYMJ [4] http://markmail.org/message/j7juyper6vhocq64 [5] http://trac.edgewall.org/query?milestone=1.0.2&milestone=0.12.6&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority [6] https://issues.apache.org/bloodhound/query?status=accepted&status=assigned&status=closed&status=needinfo&status=needinfo(new)&status=needinfo(review)&status=new&status=review&keywords=~trac-1.0.2&desc=1&order=status [7] https://issues.apache.org/bloodhound/ticket/660
