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
