On 15 January 2014 17:07, Ryan Ollos <[email protected]> wrote:

> On Wed, Jan 15, 2014 at 7:07 AM, Olemis Lang <[email protected]> wrote:
>
> > On Wed, Jan 15, 2014 at 4:52 AM, Joachim Dreimann <
> > [email protected]> wrote:
> >
> > > I lean towards calling it "trunk", because that should be recognisable
> > for
> > > those raising issues. 0.8dev almost suggests it is a release
> (candidate).
> >
> >
> > afaict , the issue with trunk is that it's a "movable" state of the code
> > base . Report some issue for trunk=0.8 , release 0.8 , and later
> trunk=0.9
> > ; then reporting against trunk means something else . Therefore by using
> > trunk we should have a mechanism (or documented release step) to batch
> > modify tickets (i.e. trunk => version x.y.z) .
> >
> >
> > > I
> > > think we should also encourage users to provide the revision they were
> > at,
> > > for example by calling the version:
> > >
> > > "trunk (provide rev!)"
> > >
> > >
> > I do agree , this could be a custom field combined with a ticket
> > manipulator enforcing to set that field for version=trunk
> >
> > [...]
>
>
> I have concerns about using "trunk", which are well-described by Olemis'
> comments.
>
> The reason I suggested "0.8dev" is because that is the version that will be
> seen throughout Bloodhound (e.g. in the footer, on the //About// page). If
> we have concerns about this nomenclature, the "dev" string could be changed
> in `setup.cfg`. There was a discussion about this in Trac, but I'm unable
> to locate it.
>

No need, you're both right. It slipped my mind that we already display
0.8dev in the UI.

- Joe


-- 
Joachim Dreimann | *User Experience Manager*

WANdisco // *Non-Stop Data*

e. [email protected]
twitter @jdreimann <https://twitter.com/jdreimann>

Reply via email to