[postgis-devel] trac milestones, dates

[Greg Troxel]

Jeff McKenna <jmckenna at gatewaygeomatics.com> writes:

> Maybe the easiest way is to generate your own 'custom query', such as
> this one that includes the 3.1.0 milestone:
> https://trac.osgeo.org/postgis/query?status=assigned&status=new&status=reopened&milestone=PostGIS+3.1.0&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority

Sure, but that's kind of like scrolling down to 3.1.0 :-)  Which doesn't
explain the relationship among milestones.

What I meant is that there is perhaps a logical relationship among the
milestones, but it's not apparent.

One might assume that a ticket is listed agains the lowest release in
which it is intended to be fixed.  So in that sense 2.4.9 has the most
important bugs.

Or, bugs are assigned to versions based on where they are found, which
is not necessarily related to where they should be fixed, or where they
exist.


I guess all I'm suggesing is to pick some notional date for the next set
of micro releases, and put 2.4.x on day 1, 2.5.x on day 2, 3.0 on 3, and
3.1 on 4.

And then for others, some dates that sort the milestones that are
actually intended to worked on, which I think is packaging and
management 2.0 leaving the others as wishlist milestones.

When I was running a large project with trac, I would juggle the
milestone dates so that this made sense.  or at least made sense to me :-)


But maybe it is only me that finds this confusing, in which case it's
probably best to ignore me.