On Wed, Jan 15, 2014 at 8:49 AM, Ryan Ollos <[email protected]> wrote:
> On Wed, Jan 15, 2014 at 7:26 AM, Ryan Ollos <[email protected]>wrote: > >> On Tue, Jan 14, 2014 at 8:48 PM, Olemis Lang <[email protected]> wrote: >> >>> On 1/14/14, Ryan Ollos <[email protected]> wrote: >>> > 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. >>> > >>> >>> 1.0-stable is a branch name , isn't it ? or is it a fixed changeset e.g. >>> tag ? >>> >>> > 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. >>> > >>> >>> I see your point ... >>> >>> [...] >>> > >>> > 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]. >>> >>> +1 >>> >>> > A shorter release cycle for Trac will allow us, with some planning, to >>> > align the Bloodhound releases with those of Trac. >>> >>> that would be awesome ! >>> :) >>> >>> > 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. >>> > >>> >>> I'd definitely like to join the trac-dev team , if possible, to help >>> you with doing so ... but I guess this is not in your hands . >>> >>> > 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. >>> > >>> >>> overall that's good news >>> >>> [...] >> >> >> >> Yes, 1.0-stable is a branch name. Revisions from this branch are tagged >> as the releases are made: 1.0.1, 1.0.2, .... >> > > > One additional link for reference - here is the most recent discussion > that I'm aware of on the release cycle for Trac, suggesting 3 month cycle > for minor releases: > https://groups.google.com/d/msg/trac-dev/17DO_N1MM-A/uu8Z1brd4LMJ > I dropped 1.0-stable at r12502 to https://svn.apache.org/repos/asf/bloodhound/vendor/trac/1.0-stable I propose to periodically drop the latest from trac 1.0-stable on this branch and then merge to bloodhound trunk.
