Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of ryan.ollos@wandisco.com
 designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
Date: Tue, 15 Jan 2013 11:27:59 -0800
Message-ID: 
 <CAPt9QwQTSxLKdyVYm0XKSc9uenCquHPe8ribpYviW6noopTjnA@mail.gmail.com>
Subject: Trac 1.0.1 vs 1.1.1 (was: Update versions in setup.py files to 0.4.0
 for all bloodhound plugins)
From: Ryan Ollos <ryan.ollos@wandisco.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9340ae37180dd04d358c29a

--14dae9340ae37180dd04d358c29a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 15, 2013 at 8:54 AM, Olemis Lang <olemis@gmail.com> wrote:

> [...]
> > Is there a particular reason to move away from 1.0 yet?
> >
>
> 0.12.5 , 1.0.1 and 1.1.1 should be scheduled for release this week or
> any time soon .


This leads into a question I've been meaning to raise: will we move to Trac
1.1.1 (development release) or 1.0.1 (stable release)? The Trac release
scheme is described on the roadmap (1).

Moving to the development release has some advantages:
 * Integrate changes pushed to the Trac core without waiting for the
typical 2 year release cycle for major stable releases, and to keep our
patched copy of Trac better aligned with the Trac trunk. We will inevitably
diverge a bit from the Trac trunk as we make changes that are necessary to
support Bloodhound features, but the hope is that eventually those changes
we make to our copy of Trac will be pushed back to the Trac repository and
our copy of Trac becomes re-aligned with the Trac releases.
 * Easier to account for necessary template modifications in small
increments rather than absorbing them in a huge batch (e.g., issues such as
#354 [2] and #335 [3]).
 * Trac does a good job at keeping their trunk stable and they even run the
latest trunk on t.e.o. Until Bloodhound becomes much more mature and is
supporting a large user base, I think we are okay with this approach.

... but there are also some challenges with moving to the development
release:
 * Changes to the Trac core will need to be tracked more carefully since
changes to the API may not be (well) documented by the time of a
development release, and there will have been less testing of this release.
I've been paying a lot of attention to what is going on in the Trac core
and willing to support this as we go forward.
 * As mentioned on the Trac Roadmap page (1), changes to the API may cause
plugins to break, and being on a development release will give less time
for plugin authors to make the necessary changes.

There isn't much "must-have" stuff in 1.1.1 yet (4), except the Datetime
field stuff would be nice. I'm confident that there will be stuff in 1.1.2,
or even 1.1.1 by the time it's released, that I'll consider "must-have"
(e.g. tickets I've been working on in the Trac core ;)

(1) http://trac.edgewall.org/wiki/RoadMap
(2) https://issues.apache.org/bloodhound/ticket/354
(3) https://issues.apache.org/bloodhound/ticket/335
(4)
http://trac.edgewall.org/query?status=assigned&status=closed&status=new&status=reopened&milestone=1.1.1&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=severity&col=time&col=changetime&order=time

--14dae9340ae37180dd04d358c29a--